Tach zusammen und gleich mal im Voraus Danke für alles und eine ernstgemeinte Entschuldigung für die Auslösung der folgenden Glaubenskriege. Ich bastel ja seit einigen Jahren jetzt mit 8bit AVRs, aber wenn ich mir so die Entwicklung der MCs anguck drängt sich mir langsam die Frage auf: Ist AVR noch "zeitgemäß"? Oder "muss" man, wenn man MC "ernsthaft" betreiben will als Hobby sich umorientieren in Richtung ... ja, was eigentlich? ARM? Und wenn, welchen (ist ja nicht so dass es ARMs selbst einfach mal "so" von der Stange von ARM selbst gibt). Klar kommt jetzt die Standardantwort "nu, kommt druff an was Du vor hast". Für's blinken Lassen von einer Handvoll Leds tut's der ATmega88 ja spielend. Jetzt bin ich über die Phase soweit allerdings drüber, hab so ziemlich alles beleuchtet was nicht bei 3 auf'm Baum war, die Katze traut sich nicht mehr in die Nähe des Löttisches (was so auch gewollt ist) und ich kenn die 8bit Atmels recht gut und intim, hab diverses an Programmier- und Debuggerätschaft dafür angeschafft und kenn mich inzwischen auch schon halbwegs damit aus. Schon deswegen tät ich gern dort bleiben. Nur geht das wenn ich mal "mehr" will? Die 32bit Atmels scheinen (und bitte korrigiert mich wenn ich da falsch liege) mehr oder weniger von Euch ignoriert worden zu sein. Zumindest find ich zu diesen eher wenig bis gar nix hier drin. Wohin gehen also die verehrten Kollegen wenn 20MHz und 128kB Flash nicht mehr zum gewünschten Ergebnis führen? Was mich in Zukunft interessieren wird ist vor allem Vernetzung und WPAN/WBAN. Sieht unheimlich interessant aus, nur hab ich damit noch herzlich wenig zu tun gehabt (und da werd ich Euch sicher auch noch kräftig auf die Nerven gehen mit, versprochen!). Hat schon jemand realisiert? Und wenn, womit? Und wohin geht der Trend allgemein (man will ja nicht nach 2 Jahren und einigen 100 Euros Investition in eine Technologie draufkommen dass man auf'm toten Pferd sitzt). Merci!
Heinz L. schrieb: > Klar kommt jetzt die Standardantwort "nu, kommt druff an was Du vor > hast". Ja und das ist auch genau der Punkt. Eine universale Antwort auf deine universale Frage existiert halt einfach nicht. 8 bit AVRs kann man für alle Projekte nehmen, für welche 8-Bit AVRs ausreichend sind. Da gibts wenig zu philosophieren. DIE Antwort welcher Controller für alles gut ist, billig, zukunftsfähig usw. usw. gibt es halt nicht. Und an bestimmten Anwendungen, wie dein WLAN, lässt sich das schon mal gar nicht festmachen, weil es zig Möglichkeiten gibt und man natürlich auch mit 8-Bit AVRs WLAN machen kann. Module gibts dafür genug. Also die ganze Fragestellung ist IMO für die Katz.
Heinz L. schrieb: > Für's blinken Lassen von einer Handvoll Leds tut's der ATmega88 > ja spielend. Richtig. Spielend. Auch für sehr viel mehr noch, wenn via UART/SPI/TWI entsprechende Hardware angebunden ist. > Nur geht das wenn ich mal "mehr" will? > wenn 20MHz und 128kB Flash nicht mehr zum > gewünschten Ergebnis führen? Was willst -DU- denn mehr? Welches Ergebnis strebst -DU- denn an? Allein das ist doch der Maßstab, nicht die Antworten auf > Ist AVR noch "zeitgemäß"? Oder "muss" man, wenn man MC "ernsthaft" > betreiben will als Hobby sich umorientieren in Richtung ...
Heinz L. schrieb: > Die 32bit Atmels scheinen (und bitte korrigiert mich wenn ich da falsch > liege) mehr oder weniger von Euch ignoriert worden zu sein. Ob man ATSAM3, STM32 oder LPC17xx nimmt, ist so ziemlich egal, es sind ja alles ARM Cortex-M3.
Die 8-Bitter haben den Charme, daß man da noch Programme vollständig selber erstellen und auch überblicken kann. Sobald man OS und Vernetzung will, geht der Überblick verloren und man kann nur noch fertig erstellte Bauklötzchen auf fertig erstellter Hardware zusammen stecken. Ich bin ja schon froh, daß ich es geschafft habe, Ordner des Notebook auf dem Desktop freizugeben, was ziemlich tricky ist. Was dafür alles im Hintergrund werkeln muß, ist mir aber gänzlich schleierhaft. Prinzipiell hätte ich auch Lust, mit der FB des Stereoreceivers über Ethernet den VLC-Player auf dem Desktop zu bedienen. Aber ich weiß, daß es praktisch unmöglich ist, die Software entsprechend zu pimpen.
Ich denke mal, ein normaler Hobbybastler wird nur selten an die Grenzen eines AVRs kommen. Der Programmierstil trägt auch hier maßgeblich zum Erfolg bei. Schlecht programmiert zwingt man auch einen M4 schnell in die Knie. Ich behaupte mal, dass 80% der Hobbybastler nur 50% der Leistung eines AVRs benötigen bzw. garnicht in der Lage sind, das Ding mit vernünftiger Programmierung an die Leistungsgrenze zu bringen.
Also wenn ich mal an die Grenze von dem AVR stoße, dann hab ich eigtl. so einen Riesen Haufen Code, dass sich eigtl. schon ein embedded Linux lohnen würde. Grade wenn ich nicht den letzten Cent aus meiner Bastelei rausgeizen will.
Peter Dannegger schrieb: >> Die 32bit Atmels scheinen (und bitte korrigiert mich wenn ich da falsch >> liege) mehr oder weniger von Euch ignoriert worden zu sein. > > Ob man ATSAM3, STM32 oder LPC17xx nimmt, ist so ziemlich egal, es sind > ja alles ARM Cortex-M3. Denke er spielt hier auf die AVR32 an...
Das einzige wo der AVR tatsächlich an seine Grenzen kommt ist, wenn man schnell viele Daten mit dem ADC aufnehmen und auswerten muss. Oder man halt große Datenmengen verarbeiten muss z.B. MP3 Ansonsten reichts aber immer locker aus...
Max D. schrieb: > die Grenze von dem AVR kann allenfalls erreicht sein wenn - der Steuerung intensive Berechnungen zugrunde liegen - grosse Datenmassen (z.B. Multimedia) bewegt/verarbeitet werden müssen - "moderne" Programmiermethoden (OOP) zur Anwendung kommen sollen. Ansonsten kann ganz einfach gelten, ob für Datenübertragung/Netzwerk, Datenspeicherung, einfache Sound/Videoausgabe: für jeden Zweck ein passendes UART/SPI/TWI steuerbares Spezialmodul.
Ben schrieb: > Peter Dannegger schrieb: >>> Die 32bit Atmels scheinen (und bitte korrigiert mich wenn ich da falsch >>> liege) mehr oder weniger von Euch ignoriert worden zu sein. >> >> Ob man ATSAM3, STM32 oder LPC17xx nimmt, ist so ziemlich egal, es sind >> ja alles ARM Cortex-M3. > > Denke er spielt hier auf die AVR32 an... Das denke ich auch. @TO: AVR32 sind keine ARM-irgendwas sondern eine ATMEL-Eigenentwicklung. Ich an Deiner Stelle würde eher ARM-Controller bevorzugen, wenn ich Richtung 32-Bitter gehen wollte, einfach weil das z.Zt. der Mainstream ist. Du bekommst dafür einfach leichter alles, was Du dafür brauchst.
Heinz L. schrieb: > Nur geht das wenn ich mal "mehr" will? Mehr als was? Es gibt in der Welt eine gigantische Mengen an eingebetteten Systemen, die mit einem 8-Bitter völlig zufrieden sind. Sieh Dir mal an, wieviele Siemens-SPS'en mit ihren 8051ern unterwegs sind. In meinem Hightech-Virtual-Analog-Synthesizer (Access Virus) steckt ein C535 drinn. In meinem Funk-Garagentorantrieb steckt ein AVR drinn. Und die tun alle ein wenig mehr als nur ein paar LEDs blinken lassen ;)
Vorneweg (EDIT): Es schadet nicht, sich mit der Entwicklung für einen 32Bit-Kern zu befassen. Zum Bleistift einem LPC... oder einem der TI ARM Launchpads oder einem STM Discovery. --- Ich würde die Grenze, ab der sich eventuell ein 32Bitter lohnt mal so ungefähr auf 64kBytes Code und 8kBytes RAM setzen. ODer eben, falls massive Berechnungen nötig sind (MP3, Video, ...) Alles drunter ist klassiches 8Bit-Terrain, wo die höher integrierten ARMs einem das Leben nciht unbedingt schwerer, aber oft auch nicht einfacher machen. Drüber ist es oft sowieso der Fall, dass am AVR schon soviel externe Peripherie dranhängt, dass man ansich auch gleich einen größeren Controller nutzen kann, dann halt gleich einen 32Bitter, der ja auch mehr Peripherie intus hat. Es gibt ansonsten ettliche Dinge, in denen ein 8Bit drinsitzt. Gesehen: Viel Laborequipment, Bühnenbeleuchtung (hier oft gleich mehrere), in Studiotechnik als Submodul (zB einer pro Buttonpanel). Ich war auch überrascht, wie oft ein ATMega zusammen mit einem Ethernetchip in allerlei Netzwerk-auf-sonstwas-Stöpseln ist. Für die 8Bit-Chips spricht da oft die Einfachheit und die oftmals robusteren IOs (weil größere Strukturbreite). Von daher ist es halt wirklich ein "Kommt drauf an". ARM und Co erlauben einem oft, das gleiche ohne optimierten Code zu erreichen. Wenn man an den Punkt kommt, wo einem beim AVR einfach die Peripherie nicht mehr reicht, man mit jedem Byte RAM am hadern ist oder "einfach mehr Wumms" braucht, sollte man zB einen ARM nehmen, statt sich ewig mit dem 8Bitter rumzuärgern. Wenn man allerdings sowieso Netzwerk, Filesystem und mehrere Tasks haben will, geht man tendenziell am besten gleich weiter zu RTOS oder Linux. ECOS ist relativ mächtig und halbwegs frei. Das sollte noch ohne MMU und ohne allzuviel RAM laufen. Linux ist halt eine andere Hausnummer. Ohne externes SDRAM wird das meistens nix. Da gibt es aber außer dem RasPi, der einfach zu wenig IOs hat und - mit Verlaub - bescheiden dokumentiert ist, ettliche andere Lösungen, von den direkten Konkurrenten bis hin zum System-On-SODIMM.
:
Bearbeitet durch User
Also ich würde mich schon als AVR Fan, und auch Kenner, bezeichnen, und die Grenze recht hoch ansetzen. Ich bin manchmal selbst verblüfft, was mit den 8-Bittern machbar ist. Wenn mir Einer nicht reicht, vernetze ich halt Mehrere per UART, SPI, oder TWI. Gerade wenn zeitkritische Sachen, wie z.B. schnelle Software-PWM auf mehreren Kanälen, im Spiel sind, ist das Softwaretechnisch eventuell sogar einfacher, als Alles auf einem dicken Controller zu machen. Und die starken IO-Pins ersparen Einem so manchen Treiberbaustein. Mit freundlichen Grüßen - Martin
Andreas Lang schrieb: > Wenn man an den Punkt kommt, wo einem beim AVR einfach die Peripherie > nicht mehr reicht ... heißt die logische, codekompatible Fortsetzung Xmega! Die sind in der Peripherie sehr gut ausgestattet, z.B. ein XmegaA1 mit 8 UARTs. Daneben viele weitere innovative Features (z.B. Event-System. > man mit jedem Byte RAM am hadern ist ... lässt sich der Xmega auch mit RAM erweitern. So es sich nicht generell um eine datenintensive Anwendung handelt bringt der bei AVRs immer noch simple, überlegte Einsatz von Assembler meist genug Abstand zum Speicher-Blackout. > oder "einfach mehr Wumms" braucht ... was für die hier behandelten Steuerungsanwendungen ohne große Mengen an Daten und Berechnungen selten nötig ist, vor allem nicht in Assembler ;-) > statt sich ewig mit dem 8Bitter rumzuärgern. Aber woher denn. 8bittig einfach=Freude. 32bittig kompliziert=Ärger Wenn die Controllerentwicklung weiter nur stur auf Leistungserhöhung, verkomplizierende Flexibilität und komplexitätssteigernde Features setzt ist der Einsatz der einfachen 8Bitter in ihren vielfältigen Anwendungsmöglichkeiten noch in hundert Jahren angezeigt.
Und der Mobby trollt schon wieder. Warum unterstützt du nicht mit deinem großen und umfassenden Wissen in Threads zu avr Problemen? Wohl nur, weil du selber keine Ahnung hast. :-( Da du selber nie über eine blinkende LED hinaus gekommen bist, wirst du auch nie die Grenzen eines ATiny erreichen. :-P Der TO hat die richtige Frage gestellt. Jetzt ist der richtige Zeitpunkt, sein Wissen zu erweitern. Ganz ohne Druck und für kleines Geld kann man mit den vielen ARM Einsteigern hier im Forum lernen. Es ist einfacher, einen kleinen ARM zu erziehen, als verteilte Systeme mit mehreren Rechnern aufzubauen. Spätestens, wenn es nicht nur um Sensoren und Aktoren geht, oder zeitkritische Abläufe eine Rolle spielen.
Moby schrieb: > heißt die logische, codekompatible Fortsetzung Xmega Und das sind nun keine AVRs mehr, oder wie? > Aber woher denn. > 8bittig einfach=Freude. > 32bittig kompliziert=Ärger Schön, wenn man in solch einfachen Denkmustern arbeiten kann. Gerade die Peripherie eines Xmega hat durchaus die Komplexität dessen, was man auch in den kleineren ARMs findet, und „codekompatibel“ zu den alten AVRs ist da peripherieseitig rein gar nichts mehr. Für reine Berechnungen ist C-Code wiederum auch zwischen 8- und 32-Bit-CPU kompatibel.
Pro Innovation schrieb: > Es ist einfacher, einen kleinen ARM zu erziehen, als verteilte Systeme > mit mehreren Rechnern aufzubauen. Keineswegs. Auch hier gilt wieder: für jeden Zweck die passende Lösung.
Also ich würd dir empfehlen, dir evtl. ein kleines Devboard mit intergriertem Debugger zu holen (z.b. stm32nucleo ~10€), um zu schauen, wies dir gefällt. Man muss natürlich sagen, dass man noch sehr viel auf einem AVR machen kann, aber teilweise ist einfacher, ein ARM zu nehmen, der alles hat und gleichzeitig noch oft weniger kostet. Bei ARMs programmiert man eben oft (man muss nicht) mit einer api, dass heißt mit einem größerem Abstrahierungslevel. Also --> 10€ sind nicht viel, probiers einfach mal aus (am besten noch mit ner IDE ala Em::Blocks)
Dake Sew schrieb: > programmiert man eben oft (man muss nicht) mit einer api, dass heißt mit > einem größerem Abstrahierungslevel. Also --> 10€ sind nicht viel, > probiers einfach mal aus (am besten noch mit ner IDE ala Em::Blocks) Heißt wohl Richtung Arduino auf höherem Level?
Es gibt keine pauschale Antwort. 8-Bitter werden immer zeitgemäß sein (der 8051 ist angeblich der häufigste Prozessorkern). Es gibt sogar noch 4-Bitter, für Hochvolumensachen. Andererseits muss sich heute keiner mehr mit Gewalt Assembler auf einem ATTINY geben. Beides hat seine Anwendungen. Das ist wie mit Küchenmesser und Kettensäge. Mit beidem kann man Bäume fällen, und mit beiden kann man Essen schneiden. BEi µC.net läufts dann so: Will man sich eine Scheibe Salami abschneiden, kommen die Modernisierungsfanatiker (STM32-Kirche) und wollen dir mit Gewalt die Kettensäge reindrücken. Das Messer wäre nicht zeitgemäß. Will man eine 1-m-Buche fällen, kommen die Optimierer (ATTINY-Assembler-Fraktion) und wollen mir das Brotmesser verkaufen. Es heißt dann, das wäre nicht schwierig, man müsse nur optimal sägen.
Pro Innovation schrieb: > Und der Mobby trollt schon wieder. Schon klar, gleich die Trollvorwurf auspacken. Bloß nicht auf das Gesagte eingehen, lieber mit > Wohl nur, weil du selber keine Ahnung hast. :-( > Da du selber nie über eine blinkende LED hinaus gekommen bist, wirst du > auch nie die Grenzen eines ATiny erreichen. :-P schnell wieder husch husch unter die Gürtellinie... Bewährte Methode, was? ;-) Aber in der Tat, unser Motto unterscheidet uns. Deiner zweifelhaften Innovation setze ich Pro 8-Bit Einfachheit entgegen! SimplyAVR. Jörg Wunsch schrieb: > Schön, wenn man in solch einfachen Denkmustern arbeiten kann. Und die enthält kein bischen Wahrheit ? > Gerade die Peripherie eines Xmega hat durchaus die Komplexität dessen, > was man auch in den kleineren ARMs findet, und „codekompatibel“ zu den > alten AVRs ist da peripherieseitig rein gar nichts mehr. Codekompatibel heißt doch zunächst mal gleicher Assemblercode. Die Organisation der Peripherie wurde (für Hochsprachenanwendung) optimiert, ja, aber darauf kann man sich bei Neuentwicklungen doch problemlos einstellen. Jedenfalls in Asm ;-)
Kvälla schrieb: > Heißt wohl Richtung Arduino auf höherem Level? Die Hardware ist da nicht so entscheidend, eher was für einen Prozessor an Software bereits zur Verfügung steht - muss man unbedingt ins Internet der Dinge eintauchen und den Toaster an facebook melden lassen, dass jetzt 2 Scheiben mittelbraun fertig sind, dann eher 32 bit mit einem TCP/IP-Stack, fürs Toasten an sich genügt ein kleiner PIC oder AVR, notfalls auch in Assembler. Georg
> fürs Toasten an sich genügt ein kleiner PIC oder AVR
Danke! Damit hat sich meine Stimmung schlagartig verbessert.
Kvälla schrieb: > Dake Sew schrieb: >> programmiert man eben oft (man muss nicht) mit einer api, dass heißt mit >> einem größerem Abstrahierungslevel. > Heißt wohl Richtung Arduino auf höherem Level? Also es ist NICHT so simple wie beim Arduino. Meist sind auch die Peripherals deutlich komplexer, sodass man immernoch Aufwand betreibern muss. Z.b. eine simple UART initialisierungs routine mit stm32cube:
1 | #include "main.h" |
2 | |
3 | GPIO_InitTypeDef GPIO_InitStruct; |
4 | UART_HandleTypeDef UartHandle; |
5 | |
6 | int main(void){ |
7 | HAL_Init(); |
8 | SystemClock_Config(); |
9 | |
10 | __GPIOA_CLK_ENABLE(); |
11 | __USART1_CLK_ENABLE(); |
12 | |
13 | GPIO_InitStruct.Pin = GPIO_PIN_2; |
14 | GPIO_InitStruct.Mode = GPIO_MODE_AF_PP; |
15 | GPIO_InitStruct.Pull = GPIO_PULLUP; |
16 | GPIO_InitStruct.Speed = GPIO_SPEED_HIGH; |
17 | GPIO_InitStruct.Alternate = GPIO_AF1_USART1; |
18 | HAL_GPIO_Init(GPIOA, &GPIO_InitStruct); |
19 | |
20 | UartHandle.Instance = USART1; |
21 | UartHandle.Init.BaudRate = 115200; |
22 | UartHandle.Init.WordLength = UART_WORDLENGTH_8B; |
23 | UartHandle.Init.StopBits = UART_STOPBITS_1; |
24 | UartHandle.Init.Parity = UART_PARITY_NONE; |
25 | UartHandle.Init.HwFlowCtl = UART_HWCONTROL_NONE; |
26 | UartHandle.Init.Mode = UART_MODE_TX; |
27 | UartHandle.AdvancedInit.AdvFeatureInit = UART_ADVFEATURE_NO_INIT; |
28 | HAL_UART_Init(&UartHandle); |
29 | while(1); |
30 | }
|
Also wirklich viel Möglichkeiten, dadurch aber auch komplizierter. (Es geht aber auch in der gleichen Zeilenanzahl eine Initialisierung mit Registerzugriffen zu schreiben, verkürtzt also den Code so nicht signifikant, machts aber einfacher zum lesen)
sieh es mal so..besser Du beherrscht einen AVR8 wie z.B. den fetten atXMEGA spielend mit all seinen Möglichkeiten und Tricks der Optimierung um den ADC vollwertig zu nutzen die Events einzusetzen etc pp als das Du auf eine Nummer zu groß setzt z.B. ARM und damit nur rumeierst Und ich denke der Xmega bietet wirklich bereits einen HAUFEN an Möglichkeiten wie z.B. Spannungsmessugn sogar in den negativen Bereich! (im Kleinen Rahmen!)
Wenn du dich einmal daran gewohnt hast mit 32Bit zu arbeiten, wirst du auch für kleine Sachen wie LED blinken auch nicht mehr auf AVR zurücksteigen. Ich benutze die STM32 für verschiedenste Anwendung, einige könnten sicherlich auch mit einem 8-Bitter realisiert werden, hatte allerdings nicht die Lust dazu mich erneut in die 8-Bitter einzulesen. Weil die Nachteile von 32 Bittern sind doch eher preislich bzw. die Komplexität. Für die einfachen Sachen hält sich die Komplexität in Grenzen, Preis kann mir ziemlich egal sein bei den paar Stück die ich zum Basteln brauch. Und wenns dann mal etwas komplexeres ist, nimmt man halt statt dem M3 Core einen M4, wenns was kleines ist einen M0 im TSSOP20 Gehäuse. Du musst dich aber im Programmierstil nicht groß umstellen, da im Prinzip alle der Cores sehr ähnlich sind. Ich hatte bis jetzt noch keine Probleme damit.
Moby schrieb: >> Schön, wenn man in solch einfachen Denkmustern arbeiten kann. > > Und die enthält kein bischen Wahrheit ? Ja: kein bisschen. >> Gerade die Peripherie eines Xmega hat durchaus die Komplexität dessen, >> was man auch in den kleineren ARMs findet, und „codekompatibel“ zu den >> alten AVRs ist da peripherieseitig rein gar nichts mehr. > > Codekompatibel heißt doch zunächst mal gleicher Assemblercode. Ach du Schreck! Klar, wenn man auf diesem Niveau diskutieren will, dann ist jede neue Architektur eine Hürde, die man sich nicht antut. Franz F. schrieb: > Wenn du dich einmal daran gewohnt hast mit 32Bit zu arbeiten, wirst du > auch für kleine Sachen wie LED blinken auch nicht mehr auf AVR > zurücksteigen. Muss nicht sein. Insbesondere, wenn man Dinge wie Programmer sowieso da hat, gibt es keinen Grund, nicht auch kleine MCUs für einfache Dinge zu verwenden.
Jörg Wunsch schrieb: > Moby schrieb: >> Codekompatibel heißt doch zunächst mal gleicher Assemblercode. > > Ach du Schreck! > > Klar, wenn man auf diesem Niveau diskutieren will, dann ist jede > neue Architektur eine Hürde, die man sich nicht antut. Nö, nix Schreck. Wenn Du AVR programmierst und Dir die Peripherie zu wenig wird liegt der Umstieg auf codekompatible Xmegas eben wesentlich näher als auf die völlig andere ARM-Architektur. Richtig, das ist eine Hürde, die man sich nicht antut! Es sei denn, berufliche Notwendigkeiten oder einfach der Spaß dran stehen im Vordergrund.
Jörg Wunsch schrieb: > Für > reine Berechnungen ist C-Code wiederum auch zwischen 8- und 32-Bit-CPU > kompatibel. Harhar. Ich gehe stark davon aus, dass du es selber besser weißt. Also kann es sich bei dieser Aussage nur um eine dieser sog. "Zwecklügen" handeln, wie sie bei C-lern regelmäßig zu bemerken sind. Die beliebtesten sind dabei die Performance-Lüge "moderne Compiler sind nicht zu toppen" und die deutlich variantenreichere Portabilitätslüge. Von letzterer stellt deine Aussage eine besonders perfide Variante dar. Der Gegenbeweis steht schon hier nur ein paar Threads tiefer zu lesen. Die bloße *Existenz* von Datentypen wie "fast_int8_t" beweist doch bereits das Gegenteil... Jedenfall für jeden, der auch nur ansatzweise logisch denken kann und nicht zum reinen C-Gläubigen mutiert ist. Denen ist natürlich nicht mehr zu helfen, die sind genauso borniert wie islamistische Teroristen... Immer nach dem Motto: Scheiß auf Logik, Menschenwürde oder alle sonstigen Werte normaler Menschen, Hauptsache es entspricht meinem tiefen Glauben. Dafür würde ich bedenkenlos lügen, verherrlichen und töten, denn das alles dient ja nur der Einzigen Guten Sache, von der ich zutiefst überzeugt bin...
Moby schrieb: > Wenn Du AVR programmierst und Dir die Peripherie zu > wenig wird liegt der Umstieg auf codekompatible Xmegas eben wesentlich > näher auf geht 's Mobby, Beitrag "ATXMega DMA mit Compare Match Trigger funktioniert nicht wie erwartet" zeig, was in dir steckt! >:>>>
Moby Dick und der C-Hass-Prediger. Das Zwnagsende jeder Diskussion die diesen Names verdient.
c-hater schrieb: > Die bloße Existenz von Datentypen wie "fast_int8_t" beweist doch > bereits das Gegenteil... Ja, klar. Wenn man gar keine Datentypen außer “register” hat, muss jeder Datentyp dämonisch wirken. Moby schrieb: > Wenn Du AVR programmierst und Dir die Peripherie zu wenig wird liegt der > Umstieg auf codekompatible Xmegas eben wesentlich näher als auf die > völlig andere ARM-Architektur. Aber nur, wenn man nie etwas anderes als den AVR-Assembler lernen wollte. Aber lassen wir das, die Erde bleibt für euch auch weiterhin eine Scheibe, und den Rest der Welt interessiert's etwa so, als ob ein Sack Reis in China umfallen würde.
Pro Innovation schrieb: > auf geht 's Mobby, > Beitrag "ATXMega DMA mit Compare Match Trigger funktioniert nicht wie > erwartet" > zeig, was in dir steckt! >:>>> Bevor ich mich in C einarbeite will ich Dich erst mal mit echter Innovation glänzen sehen ;-) Bastler schrieb: > Moby Dick und der C-Hass-Prediger. Das Zwnagsende jeder Diskussion > die diesen Names verdient. Nein. Du verklausulierst hier nur das erfolglose Ende jedes Versuchs, effizient programmierten 8-Bittern ihr Reich streitig zu machen ;-)
Die 8-Bitter sind ein Werkzeug das für eine bestimmte Klasse Probleme gut ist. Ein ARM ist für eine andere Klasse Probleme das richtige Werkzeug. Wenn du dich mit den 8 Bittern schon gut auskennst, was hindert dich daran für 10-30 Euro ein ARM Board zu kaufen und damit zu experimentieren und zu lernen. Ich habe auch mehr als ein Schraubenzieher oder mehr als ein Hammer. Mit einem 200g Hammer löse ich andere Probleme wie mit einem 2kg Fäustel. Mit dem 6kg Spalthammer spalte ich Meterstücke, mit dem 500g Beil hacke ich Anfeuerholz. Nimm beide Welten damit erweiterst du deinen Werkzeugsatz, damit du für jedes Problem das passende Werkzeug hast.
Jörg Wunsch schrieb: > Aber nur, wenn man nie etwas anderes als den AVR-Assembler lernen > wollte. Nein Jörg. Ich wollte nie etwas anderes, als meine vielen Projekte im Bereich Hausautomatisation realisiert zu wissen. Daß dafür bereits einfache 8-Bit Technik, effizient und simpel in Asm programmiert mehr als ausreicht kann mir nur recht sein.
Udo Schmitt schrieb: > Die 8-Bitter sind ein Werkzeug das für eine bestimmte Klasse > Probleme > gut ist. Ein ARM ist für eine andere Klasse Probleme das richtige > Werkzeug. Da ist sicher je nach Problemstellung was dran. Die Grenzen der AVRs wurden ja weiter oben schon aufgezeigt. Problematisch wird aber die Behauptung, auch die typischen 8-Bit Steuerungen, ein seher sehr weites Feld, sei besser 32bittig beackert. > Wenn du dich mit den 8 Bittern schon gut auskennst, was hindert dich > daran für 10-30 Euro ein ARM Board zu kaufen und damit zu > experimentieren und zu lernen. Reine Anwendungs-Bezogenheit? > Nimm beide Welten damit erweiterst du deinen Werkzeugsatz, damit du für > jedes Problem das passende Werkzeug hast. Das Problem, welches einen ARM erfordern würde, hatte ich noch nicht.
Dake Sew schrieb: > Z.b. eine simple UART initialisierungs routine mit stm32cube:
1 | > #include |
2 | > "main.h" |
3 | >
|
4 | > GPIO_InitTypeDef GPIO_InitStruct; |
5 | > UART_HandleTypeDef UartHandle; |
6 | >
|
7 | > int main(void){ |
8 | > HAL_Init(); |
9 | > SystemClock_Config(); |
10 | >
|
11 | > __GPIOA_CLK_ENABLE(); |
12 | > __USART1_CLK_ENABLE(); |
13 | >
|
14 | > GPIO_InitStruct.Pin = GPIO_PIN_2; |
15 | > GPIO_InitStruct.Mode = GPIO_MODE_AF_PP; |
16 | > GPIO_InitStruct.Pull = GPIO_PULLUP; |
17 | > GPIO_InitStruct.Speed = GPIO_SPEED_HIGH; |
18 | > GPIO_InitStruct.Alternate = GPIO_AF1_USART1; |
19 | > HAL_GPIO_Init(GPIOA, &GPIO_InitStruct); |
20 | >
|
21 | > UartHandle.Instance = USART1; |
22 | > UartHandle.Init.BaudRate = 115200; |
23 | > UartHandle.Init.WordLength = UART_WORDLENGTH_8B; |
24 | > UartHandle.Init.StopBits = UART_STOPBITS_1; |
25 | > UartHandle.Init.Parity = UART_PARITY_NONE; |
26 | > UartHandle.Init.HwFlowCtl = UART_HWCONTROL_NONE; |
27 | > UartHandle.Init.Mode = UART_MODE_TX; |
28 | > UartHandle.AdvancedInit.AdvFeatureInit = UART_ADVFEATURE_NO_INIT; |
29 | > HAL_UART_Init(&UartHandle); |
30 | > while(1); |
31 | > } |
und hier eine ohne Cube:
1 | // activate port A and map PA2 and PA3 pins to USART2 TX/RX
|
2 | RCC->AHB1ENR |= RCC_AHB1ENR_GPIOAEN; |
3 | GPIOA->MODER |= SHIFT2(2, GPIO_MODER_ALTERNATE); |
4 | GPIOA->AFR[0] |= SHIFT4(2, 7); |
5 | GPIOA->MODER |= SHIFT2(3, GPIO_MODER_ALTERNATE); |
6 | GPIOA->AFR[0] |= SHIFT4(3, 7); |
7 | |
8 | // activate USART2 and configure it for 460800 Baud
|
9 | RCC->APB1ENR |= RCC_APB1ENR_USART2EN; |
10 | USART2->CR1 = USART_CR1_UE | USART_CR1_TE | USART_CR1_RE; |
11 | USART2->CR2 = USART_CR2_STOP_1; |
12 | // baud rate: see reference manual section 19.3.4
|
13 | // and also the baud rate tables in this section
|
14 | //
|
15 | // USARTDIV = Clock / (8 * (2 - OVER8) * BAUDRATE)
|
16 | // 460800 Baud @ 42 MHz
|
17 | // USARTDIV = 5.6875
|
18 | // mantissa = 5
|
19 | // fraction = 11 / 16
|
20 | USART2->BRR = (5 << 4) | 11; |
Moby schrieb: > Bevor ich mich in C einarbeite Musst du nicht. Sein Problem ist rein die Bedienung der Peripherie (hier: des DMA-Controllers). Die Unterschiede zwischen C und Assembler bestehen da nur noch darin, ob du nun schreibst
1 | ldi r16, 42 |
2 | out PORTX, r16 |
oder
1 | PORTX = 42; |
Dafür brauchst du keinerlei „Einarbeitung“. > Nein. Du verklausulierst hier nur das erfolglose Ende jedes Versuchs, > effizient programmierten [...] Für deine Definition von „effizient“. Alle anderen würden in die Effizienzbetrachtung zumindest zum Teil ihre Arbeitszeit einbeziehen, und da ist einfach mal Schluss mit lustig, wenn man alles in Assembler fummeln will. Wenn dem nicht so wäre, würden auch heute noch Betriebssysteme in Assembler geschrieben werden.
Moby schrieb: > Das Problem, welches einen ARM erfordern würde, hatte ich noch nicht. Und der Rechner auf dem du diesen Beitrag geschrieben hast?
Moby schrieb: > Das Problem, welches einen ARM erfordern würde, hatte ich noch nicht. Klar kann man auch einen 160er Nagel mit einem 200g Hammer einschlagen. Ich nehme dafür dann doch lieber einen 600g Hammer. Umgekehrt nehme ich für einen 400mm Nagel um daran ein Bild aufzuhängen lieber den 200g Hammer. Und für die Schraube gar keinen Hammer. Obwohl man die Schraube auch mit dem Hammer irgendwie in die Wand bekäme.
Moby schrieb: > als meine vielen Projekte im Bereich > Hausautomatisation realisiert zu wissen Hast du denn dein großes Kühlschrankprojekt schon fertig? ;-))) Udo Schmitt schrieb: > Mit dem 6kg Spalthammer spalte ich Meterstücke, mit dem 500g Beil hacke > ich Anfeuerholz. Wenn du zwei Zahlen addierst, ist dir doch egal, ob im Hintergrund 8, 16 oder 32 Bit werkeln. Hauptsache das Ergebnis stimmt. Wenn du Auto fährst, ist dir doch egal, ob unter der Haube 3, 4 oder 6 Zylinder werkeln. Die Bitbreite hat nichts, aber auch gar nichts mit Komplexität zu tun. In 5 Jahren ist das hier ein ARM Forum und die AVR tropfen hinten raus wie jetzt die Renesas.
Bernd K. schrieb: > Dake Sew schrieb: >> Z.b. eine simple UART initialisierungs routine mit stm32cube:> #include >> "main.h" >> >> GPIO_InitTypeDef GPIO_InitStruct; >> UART_HandleTypeDef UartHandle; >> >> int main(void){ >> HAL_Init(); >> SystemClock_Config(); >> >> __GPIOA_CLK_ENABLE(); >> __USART1_CLK_ENABLE(); >> >> GPIO_InitStruct.Pin = GPIO_PIN_2; >> GPIO_InitStruct.Mode = GPIO_MODE_AF_PP; >> GPIO_InitStruct.Pull = GPIO_PULLUP; >> GPIO_InitStruct.Speed = GPIO_SPEED_HIGH; >> GPIO_InitStruct.Alternate = GPIO_AF1_USART1; >> HAL_GPIO_Init(GPIOA, &GPIO_InitStruct); >> >> UartHandle.Instance = USART1; >> UartHandle.Init.BaudRate = 115200; >> UartHandle.Init.WordLength = UART_WORDLENGTH_8B; >> UartHandle.Init.StopBits = UART_STOPBITS_1; >> UartHandle.Init.Parity = UART_PARITY_NONE; >> UartHandle.Init.HwFlowCtl = UART_HWCONTROL_NONE; >> UartHandle.Init.Mode = UART_MODE_TX; >> UartHandle.AdvancedInit.AdvFeatureInit = UART_ADVFEATURE_NO_INIT; >> HAL_UART_Init(&UartHandle); >> while(1); >> } > > und hier eine ohne Cube: > // activate port A and map PA2 and PA3 pins to USART2 TX/RX > RCC->AHB1ENR |= RCC_AHB1ENR_GPIOAEN; > GPIOA->MODER |= SHIFT2(2, GPIO_MODER_ALTERNATE); > GPIOA->AFR[0] |= SHIFT4(2, 7); > GPIOA->MODER |= SHIFT2(3, GPIO_MODER_ALTERNATE); > GPIOA->AFR[0] |= SHIFT4(3, 7); > > // activate USART2 and configure it for 460800 Baud > RCC->APB1ENR |= RCC_APB1ENR_USART2EN; > USART2->CR1 = USART_CR1_UE | USART_CR1_TE | USART_CR1_RE; > USART2->CR2 = USART_CR2_STOP_1; > // baud rate: see reference manual section 19.3.4 > // and also the baud rate tables in this section > // > // USARTDIV = Clock / (8 * (2 - OVER8) * BAUDRATE) > // 460800 Baud @ 42 MHz > // USARTDIV = 5.6875 > // mantissa = 5 > // fraction = 11 / 16 > USART2->BRR = (5 << 4) | 11; Himmel Herrgott. Und so einfach sieht z.B. die 9600er Initialisierung einer 32MHz Xmega UART in Asm aus: ldi r16,$a8 sts PORTC_DIR,r16 ldi r16,207 sts USARTC0_BAUDCTRLA,r16 ldi r16,$20 sts USARTC0_CTRLA,r16 ldi r16,$18 sts USARTC0_CTRLB,r16 Ende Gelände.
> In 5 Jahren ist das hier ein ARM Forum und die AVR tropfen hinten raus
Das vermute ich auch. Über 16bit PC's mit MS-DOS und 1,44MB
Speichermedien diskutiert schließlich auch kaum noch jemand.
Aber noch sind wir nicht so weit. Noch werden 8bit Controller in großen
Mengen eingesetzt. Sie sind keineswegs veraltet.
Für den Hobbybereich gibt es noch einen Unterschied bei der Gehäuseform: die 8 Bits µCs (PIC, AVR und 8051) gibt es überwiegend auch als DIP für einen eigene Platine, Lochraster oder das Steckbrett. Bei dem ARMs hat man überwiegend SMD mit kleinem Pinabstand, die nicht mehr jeder selber löten will. Da nutzt man dann doch lieber eine fertige Platine. Es gibt zwar auch einige wenige ARMs im DIP - das ist aber die Ausnahme. Solange man gut mit dem 8 Bit µC auskommt, ist das auch kein Problem. Wenn man so Verrenkungen wie externes RAM oder mehr als etwa 64 kB an Flash braucht, sollte man an was größeres denken. Die ARMs werden auch mit mehr Speicher nicht so viel teurer und dann ggf. günstiger als ein großer 8 Bit µC. Die Kompatibilität beim Xmega ist so eine Sache: man braucht einen anderen Programmer, hat andere Peripherie nur 3,x V und auch ähnlich kleine Bauformen. Gerade größere Dinge macht man eigentlich nicht mehr in ASM. In C ist es ziemlich gleich ob man vom AVR Mega.. zum Xmega oder ARM wechselt - man muss sich nur noch an eine andere IDE gewöhnen. Dafür hat man mehr Luft nach oben.
Thomas schrieb: > Ist ein 8 Bit AVR in Stückzahlen billiger als ein kleiner ARM? Nein, der schmale Kleine ist noch teurer. Daher schwenkt die Industrie um. Daher schwenkt der Halbleiterhersteller um. Atmel konzentriert sich aktuell nur auf seine SAMs (ARM).
die Zeit wird 's richten schrieb: > Die Bitbreite hat nichts, aber auch gar nichts mit Komplexität zu tun. Richtig, deshalb ist ja ein Xmega auch fast genauso komplex wie ein Cortex-M, siehe die bereits erwähnte Anfrage nach dem DMA-Controller. Thomas schrieb: > Ist ein 8 Bit AVR in Stückzahlen billiger als ein kleiner ARM? Das ist ungefähr so eine Frage wie die, ob ein PKW billiger ist als ein Transporter. Die Antwort vom Sender Jerewan: „Im Prinzip ja, aber …“
Moby schrieb: > Himmel Herrgott... Lass man die ganzen Kommentare und ersetz die ganzen Makros durch konstanten. Dann ist es in etwas gleich kurz und unlesbar wie deine Initialisierung.
Lurchi schrieb: > mit dem 8 Bit µC auskommt, ist das auch kein Problem noch erträglich ist etwas anderes als besser ;-)
die Zeit wird 's richten schrieb: > Hast du denn dein großes Kühlschrankprojekt schon fertig? ;-))) Da mach Dir mal keine Sorgen. Ist zwar nur ein Detail der Anwendung, aber was solls. Kann Dir aber versichern, die Temperaturmessung funktioniert hervorragend. Aber danke der Nachfrage. Ulrich F. schrieb: > Moby schrieb: >> Das Problem, welches einen ARM erfordern würde, hatte ich noch nicht. > Und der Rechner auf dem du diesen Beitrag geschrieben hast? Das interessiert jetzt in wiefern? Hatte ich den Sinn der ARM Welt für größere Consumer-Elektronik infrage gestellt? Thomas schrieb: > Ist ein 8 Bit AVR in Stückzahlen billiger als ein kleiner ARM? Welchen Bastler interessiert der Preis (ggf. der Unterschied in Cents) wenn die Realisierung 8-bittig so einfach ist? Einfachheit kostet ;-)
Stefan Us schrieb: >> In 5 Jahren ist das hier ein ARM Forum und die AVR tropfen > hinten raus > > Das vermute ich auch. über diesen Witz lache ich immer wieder gern. Die einfachste Lösung wird sich immer halten. Nehmt als Beispiel die einfache RS232. Kommen immer noch viele Rechner und andere Elektronik damit raus. Warum wohl? Aber klar doch, mit USB->Seriell Wandler ists einfach cleverer ;-)
Thomas schrieb: > Ist ein 8 Bit AVR in Stückzahlen billiger als ein kleiner ARM? Moby schrieb: > Himmel Herrgott. > Und so einfach sieht z.B. die 9600er Initialisierung einer 32MHz Xmega > UART in Asm aus: > > ldi r16,$a8 > sts PORTC_DIR,r16 > ldi r16,207 > sts USARTC0_BAUDCTRLA,r16 > ldi r16,$20 > sts USARTC0_CTRLA,r16 > ldi r16,$18 > sts USARTC0_CTRLB,r16 > > Ende Gelände. Du schreibst auch 3 Register im UART und eins um nen Port zu konfigurieren. Ich schreibe ebenfalls nur 3 Register im UART (nämlich CR1, CR2 und BRR, hier also Gleichstand), das aktivieren des Clock-Gatings bevor man die Peripherie nutzen kann ist normal bei ARM, Du hingegen musst wahrscheinlich ungenutzte Peripherie umständlich ausschalten weil sie per Default an ist, hier also auch Gleichstand. Bleibt das Konfigurieren der Pin-Alternate Register. Aber Du musst ja auch irgendwas am Portpin konfigurieren, also nicht viel anders. Gegen Deine Variante spricht daß Du unbenannte Konstanten verwendest (was bedeuten die magischen Zahlen 18 oder 20 oder 207 oder a8? Bitte geb den Dingern sprechende Namen und schreib auch dazu wie die Baudrate zusammenkommt, das ist bestimmt nicht vom Himmel gefallen. Was soll also das "Himmel Herrgott"? Mach erstmal Deinen undurchsichtigen Code leserlich!
:
Bearbeitet durch User
Moby schrieb: > die Realisierung 8-bittig so einfach ist Da du ein unbegründete persönliche Abneigung gegen ARM (oder nur Angst vor neuem) hast, vergleich doch einmal den AVR mit einem RC8 oder MSP430. Beides 16 Bit µCs. Hälst du die auch für komplizierter?
Moby schrieb: > ehmt als Beispiel die einfache RS232. > Kommen immer noch viele Rechner und andere Elektronik damit raus. Welcher aktuelle Laptop hat den Port noch? Das war ein Eigentor. ;-)
Bernd K. schrieb: > Gegen Deine Variante spricht daß Du unbenannte Konstanten verwendest > (was bedeuten die magischen Zahlen 18 oder 20 oder 207 oder a8? Bitte > geb den Dingern sprechende Namen und schreib auch dazu wie die Baudrate > zusammenkommt, das ist bestimmt nicht vom Himmel gefallen. Schau dir Mobbys Kühlschrankprojekt an und du stellst solche Fragen nicht mehr. ;-)))
>> Ist ein 8 Bit AVR in Stückzahlen billiger als ein kleiner ARM? > Das ist ungefähr so eine Frage wie die, ob ein PKW billiger ist als ein Transporter. Welchen Argumente sollte es (wenn es um Stückzahlen) geht sonst noch geben, außer dem Preis? Ist der 8Bit AVR der PKW? Ist er schneller als der Transporter (ARM)? Hat er weniger Spritverbrauch als der Transporter? Ist er komfortabler als der Transporter? Ist er wendiger als der Transporter? >> Ist ein 8 Bit AVR in Stückzahlen billiger als ein kleiner ARM? > Welchen Bastler interessiert der Preis (ggf. der Unterschied in Cents) Für einen Bastler spielt der Preis keine Rolle, aber der Bastler hat auch keine Stückzahlen. > wenn die Realisierung 8-bittig so einfach ist? Einfachheit kostet ;-) Ist ein 8-bitter einfacher zu programmieren als ein 32-bitter? Wenn ja, warum?
die Zeit wird 's richten schrieb: > Welcher aktuelle Laptop hat den Port noch? Bei den Dockinstations eines Business-Laptops bekommst du sogar noch einen Parallelport. (Hab' meinen Augen kaum getraut.) Einen seriellen Port haben selbst viele Noname-PCs nach wie vor.
Hallo, mit den AVR32 arbeite schon seit ein paar Jahren sehr gerne, ich finde den Aufbau der Peripherie sehr homogen und gut verständlich. z.b. wenn es x Timer gibt, dann sind alle x Timer gleich aufgebaut. Ich habe bisher auch keine sporadischen Fehler wie z.B. bei der STM32F4 I2C Peripherie. Allerdings setzt Atmel inzwischen auch viel mehr auf die ARM Cores, so dass ich für einen Neueinstig die AVR32 nicht ans Herz legen würde. Im Atmel Studio sind ja für verschiedene Cores die entsprechenden GNU Compiler dabei. Dabei hat der AVR32 den ältesten Revision Stand. Falls man also ganz moderne C++ Sprache Elemente nutzen will, geht das sehr wahrscheinlich am schlechtesten mit den AVR32. Mit den Cortex basierten Controllern von Atmel habe ich keine Erfahrung. Nur wenn ich wieder mal auf eine Ungereimtheit bei den STMF4 stoße, dann schau ich mir das Datenblatt eines vergleichbaren Atmel an und muss sagen, dass auch bei den SAM den Aufbau der Peripherie viel homogener finde. Ein paar Peripherie Einheiten sind wohl auch von den AVR32 wieder benutzt. Von einem ATmega auf eine Xmega umzusteigen halte ich nicht für eine gute Idee. Wenn der ATmega nicht mehr reicht, dann wird man auch schnell bei einem XMega an die Grenze stoßen. Also sollt man schon auf einen 32 Bitter gehen. Die Software Entwicklung im Embedded Bereich ist ja deshalb so Aufwändig, weil man immer mit Resourcen Knappheit zu kämpfen hat. Und das ist einfach bei den modernen 32 Bittern lange nicht so dramatisch. So das man seine Energie tatsächlich mehr auf sauber geschrieben, wiederverwendbaren und wartbaren Code verbrauchen anstatt dauernd irgendwelche Resourcen Grenzen im Auge zu haben. Mfg
Jörg Wunsch schrieb: > Einen seriellen Port haben selbst viele Noname-PCs nach wie vor. Aber die Welt nutzt Laptops und Tablets. Die haben keinen RS232. ;-)
Eine genagelte Schraube hält besser als ein geschraubter Nagel. Trotzdem beides eine besch...eidene Idee. In diesem Sinne: Gehirn einschalten und richtigen µC wählen. Wenn ich ein Display Charlieplexen will, dann helfen mit z.B. die fantastillionen MIpS von nem ARM herzlich wenig solange der Ausgangstreiber nur müde 25mA@3,3V und 120 mA Gesamtstrom liefert. Hier will ich einen AVR mit 40mA und 5V (200 mA ges. btw). Gegenbeispiel: Ein TCP/IP-Stack kann man zwar auf einen AVR quetschen, will man sich aber nicht antun. Eines kann man sich SICHER sein: Sollte je ein Hersteller die perfekte allesumfassende µC-Lösung finden (ein Spagat der wohl nicht funktionieren kann), dann merkt man das rechtzeitig. Bis dahin: freuen, dass wir nicht mit Lochkarten hantieren müssen.
Bernd K. schrieb: > Mach erstmal Deinen > undurchsichtigen Code leserlich! Das ist nicht 'mein' Code, sondern schlicht 'der' Code zur entsprechenden Initialisierung. Da nimmt man sich das Datenblatt und notiert die entsprechenden Registerwerte. Mach mal da keine Wissenschaft draus. Welche Notation mit welcher Architektur und Sprache hier nun undurchsichtiger, aufwendiger und komplexer daherkommt darüber muß man sicher nicht streiten ;-) die Zeit wird 's richten schrieb: > Schau dir Mobbys Kühlschrankprojekt an und du stellst solche Fragen > nicht mehr. ;-))) Ja ja... schaus Dir an. Der Sinn für 'Keep it simple' kann nicht oft genug gestärkt werden ;-) Aber lass man. Auch in 20 Jahren wird ARM hier nicht zu DEM Bastlerobjekt der Begierde, bleibt 8 Bit Nummer 1. Die Zeit wirds schon richten ;-)
Moby schrieb: > Welche Notation mit welcher Architektur und Sprache hier nun > undurchsichtiger, aufwendiger und komplexer daherkommt darüber muß man > sicher nicht streiten Jetzt wird 's spaßig. Die ASM Mauer ist in Mobbys Hirn schon gefallen. Dann fällt der 8 Bit Wall bestimmt auch bald. ;-)
die Zeit wird 's richten schrieb: > Jetzt wird 's spaßig. Nein, wird's nicht. Du verstößt gegen die Nutzungsbestimmungen und nimmst an dieser Diskussion mit verschiedenen Namen teil. Troll dich.
Moby schrieb: > Das ist nicht 'mein' Code, sondern schlicht 'der' Code zur > entsprechenden Initialisierung. Da nimmt man sich das Datenblatt und > notiert die entsprechenden Registerwerte. Wo? Ich seh keine Notizen!
DerDan schrieb: > Die Software Entwicklung im Embedded Bereich ist ja deshalb so > Aufwändig, weil man immer mit Resourcen Knappheit zu kämpfen hat. Und > das ist einfach bei den modernen 32 Bittern lange nicht so dramatisch. > So das man seine Energie tatsächlich mehr auf sauber geschrieben, > wiederverwendbaren und wartbaren Code verbrauchen anstatt dauernd > irgendwelche Resourcen Grenzen im Auge zu haben. Wobei wir nun im industrieellen Umfeld angekommen wären mit ganz anderen Prämissen. Der Grund für Ressourcenknappheit aber ist selbst in Hobbybastlerkreisen bekannt: Ineffiziente (OOP) Hochsprachenprogrammierung. Was bin ich froh, mir das als Bastler nicht antun zu müssen. DerDan schrieb: > Von einem ATmega auf eine Xmega umzusteigen halte ich nicht für eine > gute Idee. > Wenn der ATmega nicht mehr reicht, dann wird man auch schnell bei einem > XMega an die Grenze stoßen. Aber warum denn? Wenn es gerade ein paar Timer, UARTS, IOs mehr braucht soll man seine schöne Codebasis einfach über Board werfen? Was ist das denn für ein Verständnis von effizienter Arbeitsweise?
Moby schrieb: > Aber warum denn? Wenn es gerade ein paar Timer, UARTS, IOs mehr braucht > soll man seine schöne Codebasis einfach über Board werfen? Was ist das > denn für ein Verständnis von effizienter Arbeitsweise? Wenn ich das richtig sehe, bist du ja eh Bereatungsresistent.
Moby schrieb: > Ineffiziente (OOP) Hochsprachenprogrammierung. Ah ja. Man sieht sofort: du weißt aus eigener Erfahrung, worüber du schreibst. Selbst für den AVR mit seinen (leider) leicht „vergeigten“ Registern (DDRA, PORTA, PINA, statt PIOA->DDR, PIOA->PORT, PIOA->PIN) lassen sich allemal sogar OO-Abstraktionen finden, die in der Codedichte deinem Assemblercode nicht nachstehen. Für MCUs mit orthogonaleren Peripherals ist es ohnehin kein Problem, sowas zu machen. Beispiele habe ich hier im Forum schon gepostet. Da ich aber weiß, dass dich diese nicht interessieren würden, spar' ich mir die Mühe, sie jetzt wieder auszugraben.
die Zeit wird 's richten schrieb: >> ehmt als Beispiel die einfache RS232. > Welcher aktuelle Laptop hat den Port noch? Das war ein Eigentor. ;-) Sony Full-HD-Videoprojektor, aktuelles Modell, 3D-fähig, 3000kEur, wird ferngesteuert über: Lan? Neee. Wlan? Neee. Bluetooth? Neee. USB? Auch nich. RS232? Richtig! Nur mal so als Beispiel. Der Laptop muss sich dann halt einen USB-seriell-Wandler verpassen lassen.
Timm Thaler schrieb: > Sony Full-HD-Videoprojektor, aktuelles Modell, 3D-fähig, 3000kEur Wer kauft einen Beamer um 3 Mio. €?
1 | Also es ist NICHT so simple wie beim Arduino. Meist sind auch die |
2 | Peripherals deutlich komplexer, sodass man immernoch Aufwand betreibern |
3 | muss. Z.b. eine simple UART initialisierungs routine mit stm32cube: |
4 | |
5 | #include "main.h" |
6 | |
7 | GPIO_InitTypeDef GPIO_InitStruct; |
8 | UART_HandleTypeDef UartHandle; |
9 | |
10 | int main(void){
|
11 | HAL_Init(); |
12 | SystemClock_Config(); |
13 | |
14 | __GPIOA_CLK_ENABLE(); |
15 | __USART1_CLK_ENABLE(); |
16 | |
17 | GPIO_InitStruct.Pin = GPIO_PIN_2; |
18 | GPIO_InitStruct.Mode = GPIO_MODE_AF_PP; |
19 | GPIO_InitStruct.Pull = GPIO_PULLUP; |
20 | GPIO_InitStruct.Speed = GPIO_SPEED_HIGH; |
21 | GPIO_InitStruct.Alternate = GPIO_AF1_USART1; |
22 | HAL_GPIO_Init(GPIOA, &GPIO_InitStruct); |
23 | |
24 | UartHandle.Instance = USART1; |
25 | UartHandle.Init.BaudRate = 115200; |
26 | UartHandle.Init.WordLength = UART_WORDLENGTH_8B; |
27 | UartHandle.Init.StopBits = UART_STOPBITS_1; |
28 | UartHandle.Init.Parity = UART_PARITY_NONE; |
29 | UartHandle.Init.HwFlowCtl = UART_HWCONTROL_NONE; |
30 | UartHandle.Init.Mode = UART_MODE_TX; |
31 | UartHandle.AdvancedInit.AdvFeatureInit = UART_ADVFEATURE_NO_INIT; |
32 | HAL_UART_Init(&UartHandle); |
33 | while(1); |
34 | } |
Es kann aber doch simpler sein, nimmt man einen ARM-Cortex M3 ( Arduino Due, Arduino Zero ) oder einen ARM-Cortex M4 ( Teensy 3.1 ). Dann reduziert sich der Code auf
1 | void setup() |
2 | {
|
3 | Serial.init(115200); |
4 | } |
Merke: 1. Arduino ist nicht AVR. 2. Arduino kann auch ARM sein. 3. Die richtigen Libraries können das Leben sehr einfach machen.
Moby schrieb: > Aber warum denn? Wenn es gerade ein paar Timer, UARTS, IOs mehr braucht > soll man seine schöne Codebasis einfach über Board werfen? Wo ist denn dein Assembler-Beispiel ne "schöne Codebasis"? Die Registerwerte als Magic-Number hartcodiert, nichts kommentiert, alle Bits der Register in einem Byte zusammengefasst (so dass man ohne DB die Bedeutung der Bits nicht mehr erkennen kann). Oder meintest du mit "schöne Codebasis" das ARM-Cube Beispiel? Dann muss ich dir recht geben. Da kann man gezielt über "sprechende" Defines den UART parametrieren.
Moby schrieb: > Ja ja... schaus Dir an. Der Sinn für 'Keep it simple' kann nicht oft > genug gestärkt werden ;-) > Aber lass man. Auch in 20 Jahren wird ARM hier nicht zu DEM > Bastlerobjekt der Begierde, bleibt 8 Bit Nummer 1. > Die Zeit wirds schon richten ;-) Ich frage mich, wo Du Deine Weisheiten hernimmst. Hast Du denn schon einmal einen ARM in den Fingern gehabt und ARM Assemblercode geschrieben? Oder einen anderen 32 Bitter? 68000 zB? MIPS? Z.B. diese hübschen kleinen 28-Pinner von Microchip PIC32MX1xx/2xx. Gibts sogar in DIL. Hast Du denn überhaupt einmal eine Zeile Code außerhalb Deiner AVR8-Welt geschrieben? Nicht? Wie kannst Du denn hier mitreden, wenn Du offensichtlich gar keine Ahnung hast, was links&rechts von Dir los ist? Ich habe in jungen Jahren 100k-weise Assembler-Code für 68k geschrieben, und es war eine Freude. Heute würde ich C nehmen, aber damals war es eine andere Zeit. Bedenke dabei: 68k gibts seit den frühen 80'ern. Da warst Du wahrscheinlich noch nicht einmal geboren. Damit wirst Du auch nicht mehr die ersten Acorn Archimedes ARM-Maschinen erlebt haben, die Deine Ausführungen widerlegen würden. Mein Tip: Einfach mal schweigen und hören, was die erfahrenen User zu sagen haben. fchk
>Dann reduziert sich der Code auf >void setup() >{ >Serial.init(115200); >} Das passt aber nur auf 8N1 ! Was ist wenn ich etwas anders brauche? Ich halte von den zu vereinfachten Libarys nichts. Daher kommen ja immer die Arduino User Fragen. Übrigens haben wir hier auf der Arbeit aktuell HP i7 Laptops mit RS232. Im Businessbereich nichts außergewöhnliches.
Übrigends ich verwende beide Varianten: 8- und 32-bitter, jeder hat seine Daseinsberechtigung. Platz, Preis, Stromverbrauch, Code reuse, ...
Bastler schrieb: > Ich halte von den zu vereinfachten Libarys nichts. > Daher kommen ja immer die Arduino User Fragen. Nein! Sobald ein Arduinojünger anfängt zu lesen, kanns was werden ohne dulle Fragen. Und noch ein Gegenbeweis: Ich vereinfache gerne Libs und stelle hier keine Arduino Fragen... C++ auf µC? Warum nicht? Wenns tut, ist doch alles gut!
1 | #include <Combie.h> |
2 | |
3 | //Dim2Taster LEDX(upPin,downPin,pwmPin);
|
4 | Dim2Taster LED1(A0,A1, 9); |
5 | Dim2Taster LED2(A2,A3,10); |
6 | Dim2Taster LED3(A4,A5,11); |
7 | |
8 | void setup() {} |
9 | |
10 | void loop() |
11 | {
|
12 | Handler::handle(); |
13 | }
|
Hi Heinz L. schrieb: > Tach zusammen und gleich mal im Voraus Danke für alles und eine > ernstgemeinte Entschuldigung für die Auslösung der folgenden > Glaubenskriege. Manchmal lohnt doch ein Blick in die Entstehung.... Heinz L. schrieb: > Ich bastel ja seit einigen Jahren jetzt mit 8bit AVRs, aber wenn ich mir > so die Entwicklung der MCs anguck drängt sich mir langsam die Frage auf: > Ist AVR noch "zeitgemäß"? Oder "muss" man, wenn man MC "ernsthaft" > betreiben will als Hobby sich umorientieren in Richtung ... ja, was > eigentlich? ARM? Und wenn, welchen (ist ja nicht so dass es ARMs selbst > einfach mal "so" von der Stange von ARM selbst gibt). Ja, meine Meinung, man "muss" nicht, aber kann. Du sagst es selbst "Ich bastel" und "als Hobby" Egal, wie hier die Meinung der Experten an deiner Freizeit vorbei diskutiert wird, du selbst entscheidest dich bei deinen Projekten zum Einsatz der geeigneten Mittel. Das betrifft die bereits angesprochene zeit sowie auch die damit verbundenen Kosten. Niemant hindert dich daran, z.B. mit einem raspberry oder ähnlichen Systemen zu experimentieren. Das Geschrei zur fehlenden Software ist zwar beerechtigt, aber du willst ja lernen. Und da kannst du dich genau so austoben, wie mit den bereits bekannten "kleinen" Controllern. Hast du die Ideen, dann steht dir eine neue Welt offen. Aber eine Aussage : nimm dies, nimm das, 8Bitter sind out, etc wirst du von mir nicht hören. Auch nichts zur Sprache. Es ist deine Entscheidung und letztlich das, was in deinem Kopf an Ideen rumschwirrt, das eine Richtung der Technik vorgibt. Viel Spaß weiterhin an deinem Hobby und der mittlerweile wieder mal zum Glaubenskrieg ausgearteten Diskussion. Gruß oldmax Ps: Ich weiß, gern wird mal eine Meinung oder ein Beitrag runtergemacht und mit stolz geschwellter Brust auf das eigene Expertenwissen verwiesen. Da stellt sich mir aber dann die Frage: "braucht ihr das?"
Ben schrieb: > Wo ist denn dein Assembler-Beispiel ne "schöne Codebasis"? Na das sicher nicht. Vielleicht hat sich der überzeugte Asm-Progger aber eine aufgebaut? Wer übrigens von Code erwartet, daß einem nebenbei gleich der ganze Controller erklärt wird verlangt zuviel. Dazu nehme man sich bitte das Datenblatt zur Hand. Jörg Wunsch schrieb: > lassen > sich allemal sogar OO-Abstraktionen finden, die in der Codedichte > deinem Assemblercode nicht nachstehen. Absolut. Machbar ist alles. Wird es auch gemacht? Oder wird dieser Aufwand mangels Knowhow (bzw der Zeit&Lust, dieses aufzubauen) in der Regel gar nicht getrieben? Da fällt mir doch gleich ein gewisser Thread ein, der eine umfassende Abstraktion für AVRs in C++ versprach... Gescheitert auf der ganzen Linie. Frank K. schrieb: > seit den frühen 80'ern. Da > warst Du wahrscheinlich noch nicht einmal geboren. Ein Schuß in den Ofen ;-) > Ich frage mich, wo Du Deine Weisheiten hernimmst. Aus einer ganz einfachen Erfahrung: Halte die Dinge so einfach wie möglich, dann hast Du unter dem Strich den geringsten Aufwand ;-) > offensichtlich gar keine Ahnung hast, was links&rechts von Dir los ist? Das wär in der Tat ungünstig. Aber das Interesse verebbt zugegebenermaßen schnell beim Blick in die doppelt langen, kryptischen ARM-Datenblätter und die dicken C-Bücher- wenn man denn schon die Erfahrung gemacht hat: Mit dem einfachen AVR & Asm gehts ja genauso! > Mein Tip: Einfach mal schweigen und hören, was die erfahrenen User zu > sagen haben. Sicher. Das wär für manchen natürlich die bequemste Lösung. Aber mach Dir nichts draus, ich bin auch nicht erst seit gestern dabei. Die These der allgewaltigen Machübernahme der 32Bitter haben wir hier schon gemeinsam vor geschätzt 5 Jahren diskutiert- und die war damals so lächerlich wie sie es heute ist.
Moby schrieb: >> lassen >> sich allemal sogar OO-Abstraktionen finden, die in der Codedichte >> deinem Assemblercode nicht nachstehen. > > Absolut. Machbar ist alles. Wird es auch gemacht? Nur, weil du es nicht machst (du abstrahierst ja gleich gar nichts, wie du uns stolz demonstriert hast), heißt das doch nicht, dass es deshalb nicht gemacht würde.
Moby schrieb: > Das wär in der Tat ungünstig. Aber das Interesse verebbt > zugegebenermaßen schnell beim Blick in die doppelt langen, kryptischen > ARM-Datenblätter und die dicken C-Bücher- wenn man denn schon die > Erfahrung gemacht hat: Mit dem einfachen AVR & Asm gehts ja genauso! Wer einmal begriffen hat, wie ein Hammer funktioniert, für den sehen alle Probleme plötzlich wie ein Nagel aus. > Mit dem einfachen AVR & Asm gehts ja genauso! Solange du dir deine Problemstellungen nach DIESEN Kriterien selber aussuchst, Ja! Sonst: Nein! (zumindest nicht unbedingt)
Moby schrieb: > Aus einer ganz einfachen Erfahrung: Halte die Dinge so einfach wie > möglich, dann hast Du unter dem Strich den geringsten Aufwand ;-) Der Satz gefällt mir sehr gut, auch wenn ich mich nicht immer dran halte, manchmal kommt hald der Spieltrieb durch, und es gibt, für ein paar Einstellungen, doch eine schöne Klartext-Schnittstelle, übrigens auch in AVR-ASM. Ich mache das meiste in Assembler, und mit etwas Übung, und einer guten Sammlung eigener Codeschnipsel, ist das auch nicht so umständlich. Habe mir auch ein paar Regeln angewöhnt, die dafür sorgen, daß diese Codeschnipsel, meist ohne größere Änderungen, auch in weiteren Projekten verwendbar sind. Mit freundlichen Grüßen - Martin
Die immer gleiche Diskussion, C versus ASM, AVR versus den Rest der Welt. Lasst dem Hobbyisten seine Sicht der Dinge und gut ist. Moby ist ein Hobbyist und aus seiner begrenzten Sicht ist doch die Welt in Ordnung, ich wünsch dir viel Spass mit den AVRs. C-HATER hat mit seinen Kommentaren zumindestens ein paar korrekte Einwürfe gemacht. C mag tatsächlich nicht zu 100% portabel sein aber besser als ASM ist es allemal. Ich habe selber 15 Jahre lang in ASM geschrieben, heute würde ich mir das nicht mehr antun. ASM ist aber nicht der Grund dafür sondern die Tatsache das C heute verlangt wird (im Profi Bereich). Auch hier wieder, wenns ums Hobby geht dann macht doch was ihr wollt. Macht halt keine Religion daraus. Das sich hier die Mods an der Diskussion beteiligen ist für mich nicht nachvollziehbar, die Diskussion hats doch jede Woche. Macht den Thread zu.
Moby schrieb: > Die These der allgewaltigen Machübernahme der 32Bitter haben wir hier > schon gemeinsam vor geschätzt 5 Jahren diskutiert- und die war damals so > lächerlich wie sie es heute ist. Das sehe ich anders. Der Anteil an Threads, welche 32-Bit-µCs betreffen, hat hier in der letzten Zeit sehr stark zugenommen - insbesondere für STM32. Klick mal im Hauptforum auf die Filter. Anzahl der Threads, mit heutigen Beiträgen, Stand 13:45 Uhr: ARM 4 AVR 5 Arduino 2 MSP430 1 PIC 2 Rest 0 Das ist jetzt sicherlich nicht repräsentativ. Aber mach das mal regelmäßig für ARM und AVR. ARM holt hier immer mehr auf.
:
Bearbeitet durch Moderator
Martin Schlüter schrieb: > und es gibt, für ein > paar Einstellungen, doch eine schöne Klartext-Schnittstelle, Schön dass du das erwähnst. Damit folgst du ja auch der Keep-it-simple-Devise. Eine Klartextschnittstelle ist doch viel einfacher als ein eigenes (proprietäres) Binärprotokoll. Großer Vorteil ist auch, dass die Befehle mal eben in HTerm oder Putty reingehauen werden können. Dann versende ich eben sowas wie "pwm set 3 200" als ASCII um meinen PWM-Kanal 3 auf den Wert 200 zu setzen. Is doch schön wenns so einfach geht. Keep it simple, wie Moby schon sagt. Den Satz haut man dann controllerseitig durch strktok, atoi, sscanf und Konsorten und hat in Null-Komma-Nix ein wunderschönes Interface um sein Gerät zu parametrisieren. Die paar huntert Byte Bibliothekscode und die Prozessortakte leihts mir locker auch auf nem Mega32. Klar, ich könnt das auch in nem Mega8 oder Tiny2313 quetschen und mit Assembler ein Binärprotokoll parsen...
Moby schrieb: > Na das sicher nicht. > Vielleicht hat sich der überzeugte Asm-Progger aber eine aufgebaut? > Wer übrigens von Code erwartet, daß einem nebenbei gleich der ganze > Controller erklärt wird verlangt zuviel. Dazu nehme man sich bitte das > Datenblatt zur Hand. Natürlich muss man das DB verwenden. Aber wenn man z.B. die CMSIS für die Cortex nimmt, kann man sehr sehr viel ohne ein DB machen, da die Funktionen dort soweit selbsterklärend sind. Man kann fast alles erschlagen, ohne auch nur einmal ins DB geschaut zu haben. Ob das sinnvoll ist wage ich auch zu bezweifeln, denn es schürt Halbwissen. Aber schnelle Erfolge sind damit allemal drin ;) Wäre auch nicht schlecht wenn man bitte endlich mal diese Diskussion ASM vs C beenden könnte. Jedem das Seine. Die gleich Diskussion könnte man auch über Bier und Schnapps führen. Schnapps macht schneller betrunken, Bier hingegen kann man in größeren Mengen reingießen. Und die Moral von der Geschicht, Alkohol und Programmieren verträgt sich nicht ;)
:
Bearbeitet durch User
Ingo Less schrieb: > Ich behaupte mal, dass 80% der Hobbybastler nur 50% der Leistung eines > AVRs benötigen bzw. garnicht in der Lage sind, das Ding mit vernünftiger > Programmierung an die Leistungsgrenze zu bringen. Da bist Du aber sehr großzügig. Ich schätze mal anhand der Projekte hier 90% Bastler brauchen defacto nur 10% der AVR Leistung. Aber klar sollte man besser sagen "bräuchten", weil sich Leistung natürlich so leicht wie unnötig mit schlechtem Code vernichten lässt. Max D. schrieb: > Eines kann man sich SICHER sein: Sollte je ein Hersteller die perfekte > allesumfassende µC-Lösung finden (ein Spagat der wohl nicht > funktionieren kann), Da bin ich etwas anderer Meinung. Für die Hardware-Hersteller gäbe es mehr als genug Raum, den Programmierern ihr Leben einfacher zu machen. Statt nur den dummen Rohbau hinzustellen bei dem alles aber auch jedes zu konfigurieren ist könnte man die Sache schon etwas komfortabler gestalten. Auf meiner Wunschliste stünden zum Beispiel Vielfache des Registersatzes für einen schnellen Taskwechsel mit automatischer Statussicherung ganz oben. Oder eine im Klartext konfigurierbare UART: Sende mit AA Baud ab Pufferadr BB mit Länge CC- der Rest geht dann automatisch und parallel zu allem anderen. Motto: Die Hardware intelligent machen! Statt dessen sollen es dann immer komplexere und abstraktere Softwarekonstruktionen richten. Mit dem offiziellen Ansinnen zu vereinfachen wirds unter dem Strich schleichend immer schwieriger. Bis der Irrsinn selbstverständlich erscheint. So mach ein Hochsprachler wirkt dann konsterniert wenn man dessen Codeblähung kompakten Asm Code gegenüberstellt ;-)
Moby schrieb: > So mach > ein Hochsprachler wirkt dann konsterniert wenn man dessen Codeblähung > kompakten Asm Code gegenüberstellt ;-) Ingo Less schrieb: > Wäre auch nicht schlecht wenn man bitte endlich mal diese Diskussion ASM > vs C beenden könnte. Jedem das Seine. Nu beruhig dich mal wieder. Dein ASM will dir ja keiner weg nehmen...
Meine Meinung zum TO Schau dir mal die ARM Boards von ST an. Mit gut dokumentierten Einstiegsboards (z.B. Nucleo oder Discovery) und ner schönen Abstraktion (Cube) findest Dich erstmal schnell zurecht und kannst step by step in die Tiefen der Hardware eintauchen... Mit CubeMx gibts auch ne ART von Klicki-Bunti Board Konfig, wenn es mal schnell gehen muss. Ich bin privat noch meistens mit meinen Tinys unterwegs, da die für meine Basteleien völlig reichen, aber in der Firma sind die Projekte ein wenig "massiger" und da setzen wir die STs oft ein.
Soll ich auch noch meinen Senf dazu geben? :-) Zur Zeit schwenke ich mit einem Langzeit-Projekt langsam von einem ATmega644 auf einen LPC1114FN28 um. Hauptsächlich, weil sich die zusätzliche Rechenleistung in dem Fall nutzbringend einsetzen lässt. Der Code ist von 32-bit Integern dominiert, da kann man wohl eine 5-10 Mal höhere Performance heraus holen, auch wenn der CPU-Takt nur 2,5 Mal höher ist. Ansonsten gibt es aber auch nicht mehr viele Gründe, bei den 8-Bittern zu bleiben: - Dieser -FN28 ist für Durchsteckmontage mit 2,5 mm Pinabstand, da kann man die Platinen immer noch selbst fräsen und mit einfachem Equipment löten. - Unerfahrene DIYer trauen sich das löten weiterhin zu. SMD ist für Viele immer noch ein rotes Tuch. - Bootloader ist schon fest drauf, ein Problem weniger. - Es gibt inzwischen sogar ARMs in der Grösse der ATtinys. - Funktionsumfang ist quasi gleich. - Binaries sind ähnlich klein, mit den 32 kB kann man schon was anfangen. - Der Chip kostet nur die Hälfte. Nett, auch wenn die 4-6 Euro für einen ATmega nicht gerade ein Loch ins Portemonaie reissen. Was nicht so toll ist: - Ein 40-Pin DIL Chip fehlt **grins** - Die 3,3V Signal mit wenigen mA reichen seltener zum direkten ansteuern von LEDs oder MOSFETs. - Hardware-Unterstützung durch gcc und arm-libc fehlt. Der ganze CMSIS- und MBED-Klumpatsch ist ein riesen Chaos, das braucht am Anfang erheblich mehr Aufwand als einfach ein passendes -mmcu Flag zu setzen. - ARM will Angebote/Projekte, Letzteres zu beheben, offensichtlich nicht unterstützen. ARM setzt nur auf komplette Boards, die mit fertigen Bibliotheken kommen. Als Board-Entwickler muss man sich also selbst durchwurschteln. - Insbesondere der Code in MBED geht recht verschwenderisch mit den Resourcen um. "Hello World" für die serielle Schnittstelle -> 7 kB. Die letzten Drei sind der Grund, warum ich die Migration seit Monaten vor mir her schiebe. Die Hardware ist nicht das Problem, das Board ist schon fertig.
Markus H. schrieb: > - Es gibt inzwischen sogar ARMs in der Grösse der ATtinys. Das ist allerdings eine reichlich allgemeine Aussage. Schließlich ist der kleinste ATtiny in einem SOT-23-6-Gehäuse. Da hab' ich noch keinen ARM gesehen bisher. ;-) > - Die 3,3V Signal mit wenigen mA reichen seltener zum direkten ansteuern > von LEDs oder MOSFETs. Blaue/weiße LEDs gehen dann direkt kaum noch, Direktbetrieb (ohne Regler) an LiPo auch nicht. Gerade letzteres kann manchmal nützlich sein. > - Hardware-Unterstützung durch gcc und arm-libc fehlt. Das wiederum würde mich wundern. Sind doch ganz normale Cortex-M0, warum sollten die von GCC und Newlib nicht unterstützt werden? Allerdings muss man diesbezüglich bei ARM viel mehr selbst basteln als bei AVR-GCC + Anhang. Letztere können es sich leisten, alle MCU-Typen mit ihren Eigenheiten direkt via -mmcu= zu kennen und zumindest einigermaßen optimal zu unterstützen (passender Startup-Code und impliziter Linkerscript), bei vielen ARMs gibt's dann die Linkerscriptvorschläge vom Hersteller, und selbst den Startup-Code schleppen die Leute oft in ihren Projekten mit rum. Das vergrößert natürlich die Einstiegshürde für einen Anfänger. Auf einem AVR bekommst du mit
1 | avr-gcc -mmcu=yourMCUtype -Os -o helloworld.elf helloworld.c |
dein Helloworld-Applikation praktisch aus der Dose raus passend compiliert. Beim ARM-GCC fehlt da leider eine leitende Hand; das hätte wohl ARM in die Hand nehmen müssen, denn die einzelnen Hersteller der Produkte haben allesamt kein Eigeninteresse daran, sowas zu pflegen. Da vermarktet nur jeder seine IDE, und die Dinge wie Startup-Code, Linkerscript, -mcpu= -mthumb etc. Parameter werden dann alle im Hintergrund zusammengewerkelt. > SMD ist für Viele immer noch ein rotes Tuch. Damit schränkt man sich aber zunehmend künstlich und unsinnig ein. Es muss ja nicht gleich QFN oder BGA sein.
Jörg Wunsch schrieb: > Markus H. schrieb: >> - Es gibt inzwischen sogar ARMs in der Grösse der ATtinys. > > Das ist allerdings eine reichlich allgemeine Aussage. Schließlich > ist der kleinste ATtiny in einem SOT-23-6-Gehäuse. Da hab' ich noch > keinen ARM gesehen bisher. ;-) Wie wär's denn mit einem LPC800? Das ist doch schon ziemlich nahe dran: http://www.nxp.com/products/microcontrollers/product_series/lpc800/LPC810M021FN8.html > Allerdings muss man diesbezüglich bei ARM viel mehr selbst basteln > als bei AVR-GCC + Anhang. [...] Auf einem AVR > bekommst du mit > avr-gcc -mmcu=yourMCUtype -Os -o helloworld.elf helloworld.c > dein Helloworld-Applikation praktisch aus der Dose raus passend > compiliert. Genau das meine ich. > Beim ARM-GCC fehlt da leider eine leitende Hand; das > hätte wohl ARM in die Hand nehmen müssen Eben. Ich habe mal einen Bugreport abgesetzt, um das wenigstens ansatzweise ins Rollen zu bringen, der wurde abgelehnt: https://answers.launchpad.net/gcc-arm-embedded/+question/256332 und https://bugs.launchpad.net/gcc-arm-embedded/+bug/1387906 Die winden sich hin und her. Anstatt entsprechenden Code zu akzeptieren, schreiben sie aber lieber so einen Virtualizer, der von eher esoterischem Nutzen ist, dafür aber ohne Hardware-Definitionen auskommt. >> SMD ist für Viele immer noch ein rotes Tuch. > > Damit schränkt man sich aber zunehmend künstlich und unsinnig ein. Es nutzt ja nichts, etwas zu entwerfen, was niemand haben will. Das ist Open Source, also nicht nur für mich selbst gedacht. Davon abgesehen, denke mal an Leute, die sich gerade ihren ersten Lötkolben gekauft haben, womöglich noch ohne Temperaturregelung. Da waren nicht Wenige, die sich so einen Kit bestellt und ihn damit zusammen gebaut haben. Wenn die Leute Spass haben sollen, kann man nicht Equipment für 500 Euro voraussetzen. Die, die solches Equipment haben, nehmen ohnehin lieber einen Cortex-M4 mit 100 Pins und fröhnen der Featuritis.
Markus H. schrieb: >> ist der kleinste ATtiny in einem SOT-23-6-Gehäuse. Da hab' ich noch >> keinen ARM gesehen bisher. ;-) > > Wie wär's denn mit einem LPC800? Das ist doch schon ziemlich nahe dran: > > http://www.nxp.com/products/microcontrollers/product_series/lpc800/LPC810M021FN8.html DIP-8? Du beliebst zu scherzen? Es wurde nach klein(!) gefragt, nicht nach Monumental-Brocken mit nur 8 Beinen die dafür aber so dick sind wie Baumstämme, der würde größer sein als jedes andere Bauteil auf der Platine, womöglich sogar größer als die ganze Platine insgesamt. Aber vielleicht kann man auch den Rest der Schaltung komplett unter so einem überdimensionierten Baldachin unterbringen wenn man ihn in von oben lötet, sähe bestimmt lustig aus ;-)
:
Bearbeitet durch User
Heinz L. schrieb: > Ist AVR noch "zeitgemäß"? Oder "muss" man, wenn man MC "ernsthaft" > betreiben will als Hobby sich umorientieren in Richtung [...] > > Wohin gehen also > die verehrten Kollegen wenn 20MHz und 128kB Flash nicht mehr zum > gewünschten Ergebnis führen? Zwischen 20 Mips und 80 Mips (M3) ist kein großer Unterschied, außer etwas Bequemlichkeit. Die erste Wand ist bei mir Timing und das liegt meist an der (un)passenden Peripherie. Bei straffen Timing: FPGA Wenn es viele Daten/Oberfläche gibt werde ich wohl (Klein)computer mit OS bevorzugen. (z.B. über Ethernet in den PC) > Was mich in Zukunft interessieren wird ist vor allem Vernetzung und > WPAN/WBAN. Sieht unheimlich interessant aus, Das meiste wird so speziell sein, dass ein fertiger extra Chip die Arbeit macht. Ein I2C, SPI, UART, ... Interface wird da vorhanden sein. Wohl kein Grund die AVR einzumotten. Wohl kein Grund an den AVR festzuhalten.
Markus H. schrieb: > Wenn die Leute Spass haben sollen, kann man nicht Equipment für 500 Euro > voraussetzen. SMD ist nicht gleich SMD. SOIC mit 1,27 mm Pinabstand oder SOT-23 ist auch SMD, aber aus heutiger Sicht grobschlächtig genug, dass man es mit einem ordentlichen Lötkolben problemlos mit der Hand löten kann. Aber auch und gerade die TQFP-AVRs mit niedrigeren Pinzahlen mit ihrem 0,8er Pinabstand sind noch recht gut mit der Hand zu löten. Bei TQFP mit 0,5 mm Pinabstand sollte man wohl schon etwas Übung haben und die Entlötlitze bereitliegen, damit man das überschüssige Zinn absaugen kann. Aber mit den 500 Euro übertreibst du schon reichlich. QFP lötest du schon auch noch mit 'ner billigen Lötstation, und im Gegensatz zu uns “Old Men” sind bei den Jugendlichen die Augen besser, die brauchen kein Mikroskop oder Kopflupe dazu. Die haben übrigens auch weniger Scheu vor SMD als du denkst.
Bernd K. schrieb: > Es wurde nach klein(!) gefragt Drei Klicks weiter: http://www.nxp.com/products/microcontrollers/product_series/lpc800/LPC811M001JDH16.html 3,3 x 2,6 Millimeter, 16 Pins, 0,5 mm dick. Klein genug? Mannomann, sind die Leute in diesem Forum kleinkariert.
:
Bearbeitet durch User
Jörg Wunsch schrieb: > SOIC mit 1,27 mm Pinabstand Stimmt, die gehen relativ gut. Es macht da auch nichts, wenn man zwei Pins gleichzeitig lötet. Bammel haben die Leute immer noch, aber da kann man vielleicht mit einem passenden Video abhelfen. Gibt's für Widerstände was ähnlich praktikables? Die kann man deutlich schlechter festhalten und sind bei mir bislang noch immer am Lötkolben hängen geblieben. Oder immer Lötpaste nehmen, damit man mit 2 Händen auskommt (eine für Pinzette oder Schraubenzieher zum festhalten, eine für Lötkolben)?
Markus H. schrieb: > Gibt's für Widerstände was ähnlich praktikables? 1206 > Die kann man deutlich > schlechter festhalten und sind bei mir bislang noch immer am Lötkolben > hängen geblieben. Mit einer Pinzette geht's ganz gut, > Oder immer Lötpaste nehmen, damit man mit 2 Händen > auskommt (eine für Pinzette oder Schraubenzieher zum festhalten, eine > für Lötkolben)? - Ein Pad verzinnen - Den Widerstand mit der Pinzette nehmen und am Pad anlöten - Das Zweite Pad löten
Frank schrieb: > - Ein Pad verzinnen > - Den Widerstand mit der Pinzette nehmen und am Pad anlöten > - Das Zweite Pad löten Optimiert geht das so: - für alle Bauteile: ein Pad verzinnen, idealerweise immer auf der gleichen Seite - die Bauteile mit der Pinzette nehmen und am verzinnten Pad anheften - für alle Bauteile: offene Pads löten Falls man doch mal einen Widerstand falsch gesetzt hat, merkt man das meist, wenn der Platz schon besetzt ist, und kann den einfach wieder runternehmen.
>>Dann reduziert sich der Code auf >>void setup() >>{ >>Serial.init(115200); >>} Bastler >Das passt aber nur auf 8N1 ! >Was ist wenn ich etwas anders brauche? Es ist ja keiner davon ausgegangen, dass Du prähistorische Hardware ansteuern willst. Klar, im Fall der Ansteuerung von Altgeräten kann man auch Programmiertechniken von vorgestern nutzen.
Wieso prähistorisch? Die meisten denken bei UART automatisch an RS232. Aber was ist mit Profibus, Modbus, ... Einfach nen MAX481 o.ä. anschließen und fertig. 8N1 passt da aber nicht. Ich denke da gerade an einen Spruch eines Projektmanagers: "Was? Ihr benutzt noch UART? Heute nimmt man RS485!"
Heinz L. schrieb: > AVR 8bit auch für größere Projekte? Es ist nicht richtig eine Verbindung zwischen Größe und Hirn herzustellen.
Wankel schrieb: > Es ist nicht richtig eine Verbindung zwischen Größe und Hirn > herzustellen. You made my day :D
>Profibus? Da bist Du mit einem ARM ohnehin besser aufgehoben.
Jain, für eine "normale" Datenübertragung auf jeden Fall.
Ich benutzte einen 8-bitter als Mastersimulator und nutze die Versorgung
der Terminierungswiderstände.
-> Günstig, klein, wenig Stromaufnahme.
Für Funktionstests reichen 19,2k aus.
Bastler > Das passt aber nur auf 8N1 ! > Was ist wenn ich etwas anders brauche? Bastler schrieb: > Einfach nen MAX481 o.ä. anschließen und fertig. 8N1 passt da aber nicht. (Mein) Arduino kann vielleicht mehr, als du glaubst ... > Serial.begin(speed) > Serial.begin(speed, config) vielleicht ist hier ja was dabei, um die dringendste Not zu lindern. > config: sets data, parity, and stop bits. (kann man übrigens alles in der Doku finden. http://arduino.cc/en/Serial/Begin )
Zuallererst mal Danke an alle die ernsthaften Antworten gaben, sie helfen mir weiter. Auch meinen Dank an die Trolle und Glaubenskrieger, sie geben mir eine Rechtfertigung für meine Misanthropie. Ich hatte ehrlich gehofft es ginge, ohne dass die jeweiligen Jünger der einen oder anderen Glaubensfraktion hier versuchen die Ungläuben zu bekehren. Meine Hoffnung bestand darin, dass mir jemand dabei geholfen hätte, überhaupt mal die richtigen Fragen zu stellen. Worin eben der Unterschied der einzelnen Systeme besteht. Was ist Dir wichtig? Preis? Leistung? Besonders viele wasweissichwas-Peripherieanschlüsse? So seltsam dies klingen mag, aber tatsächlich half mir der zelebrierte Glaubenskrieg. Immerhin haben die jeweiligen Jünger immer wieder die jeweiligen Vorteile ihrer Religion hervorgeholt und damit zumindest mal indirekt erklärt was bei welchen µCs wie toll ist.
Markus H. schrieb: > - Bootloader ist schon fest drauf, ein Problem weniger. Ähnliches höre ich hier öfter. Ich arbeite beruflich mit den verschiedensten Prozessoren und verstehe daher manche Anforderungen der Hobbyanwender hier nicht so recht. Was ist der Grund dafür, dass ein Bootloader gegenüber einem JTAG Zugang bevorzugt wird?
Meine Entscheidung fiel vorläufig zugunsten der AVR 8bitter. Erstens Preis. Nachdem vieles von dem was ich mache eine recht gute Wahrscheinlichkeit hat nicht lang zu leben und ersetzt werden muss ist eine der Anforderungen dass das Ganze nicht mehr als 10 Euro pro Gesamtprodukt kostet. Zweitens ASM. Ich hab halt gern Kontrolle über das Ding. Ist jetzt zugegebenermaßen mein persönlicher Spleen und nicht durch irgendwelche "objektiven" Gründe gerechtfertigt, aber ich will halt. Und da es ja mein Projekt ist und ich niemandem gegenüber rechtfertigen muss wenn da ein 2 Tages Projekt 2 Monate braucht... ich find's halt schön wenn ich irgendwas mal zur Abwechslung "elegant" lösen darf anstatt wie üblich in der Arbeit eben "hauptsach es geht". Drittens Lerneffekt. Es ist ja nett dass man bei "größeren" Chips ganze Bibliotheken an Standardfunktionen dazugeliefert bekommt, aber genau das interessiert mich eben nicht. Bei mir ist mehr der Weg das Ziel. Viertens DIP statt QFN. Die meisten kleineren AVRs kommen als etwas daher dass auch ich eher unbegabter Löter ohne Reflowstation und sonstigem Hi-Tech Kram so auf die Platine krieg dass das anschließend sogar funktioniert. Und mit dem Alter werden die Augen auch schwächer und ich will nicht ständig durch's Mikroskop gucken wenn ich 'n µC wo reinlöte.
Steffen Rose schrieb: > Was ist der Grund dafür, dass ein Bootloader gegenüber einem JTAG Zugang > bevorzugt wird? Ich vermute mal: USB-UART < 5€, JTAG sicher viel mehr.
Heinz L. schrieb: > Zweitens ASM. Ich hab halt gern Kontrolle über das Ding. Ist jetzt > zugegebenermaßen mein persönlicher Spleen [...] Wenn du das gleich im Eröffnungsposting geschrieben hättest, wäre die Entscheidung allerdings schon dort sehr eindeutig gewesen. Sicher kann man auch einen ARM in Assembler programmieren, aber wirklich Spaß macht das kaum, und man muss einiges umlernen. > Viertens DIP statt QFN. Dazwischen liegt aber noch vieles, was sich auch hobbymäßig löten lässt, das allein wäre kein Argument. Selbst die Xmegas (wenn du mal bei AVR etwas mehr Rechenleistung und bessere Peripherie haben willst) bekommt man nicht mehr in DIP. Man kann sich natürlich einen QFP->DIP-Adapter nehmen, aber dann löte bitte wenigstens noch die 100-nF-Kerkos zwischen die Vcc/GND-Paare gleich mit auf den Adapter. Hinter 2 cm Adapter-Leiterbahn sind die witzlos.
Steffen Rose schrieb: > Ich arbeite beruflich mit den > verschiedensten Prozessoren Steffen Rose schrieb: > Was ist der Grund dafür, dass ein Bootloader gegenüber einem JTAG Zugang > bevorzugt wird? Du machst das beruflich und kannst dir deine Frage nicht selbst beantworten? Echt jetzt? Wie updatet ihr denn "draußen im Feld" die Firmware?
Ben schrieb: > Wie updatet ihr denn "draußen im Feld" die Firmware? Ist ja nun nicht so, dass man für einen JTAG-Programmer extra noch einen PKW-Anhänger bräuchte. ;-)
Jörg Wunsch schrieb: > Ben schrieb: >> Wie updatet ihr denn "draußen im Feld" die Firmware? > > Ist ja nun nicht so, dass man für einen JTAG-Programmer extra noch > einen PKW-Anhänger bräuchte. ;-) Wohl aber eine Möglichkeit den JTAG-Programmer anzustöpseln, und das ist nicht immer vorgesehen.
Ob JTAG, oder SPI ist erst mal egal. Die Moeglichkeit muss erst mal gegeben sein. Wenn man das denn so vorgesehen hat.
Eric B. schrieb: > Jörg Wunsch schrieb: >> Ben schrieb: >>> Wie updatet ihr denn "draußen im Feld" die Firmware? >> >> Ist ja nun nicht so, dass man für einen JTAG-Programmer extra noch >> einen PKW-Anhänger bräuchte. ;-) > > Wohl aber eine Möglichkeit den JTAG-Programmer anzustöpseln, und das ist > nicht immer vorgesehen. Nicht gewollt oder nicht möglich. Im Automotive Bereich scheidet JTAG im Feld aus. Da sitzen die Steuergeräte irgendwo an den unmöglichsten Stellen, in nem verschlossenen Gehäuse. Und am Stecker rausgeführt werden die JTAG Pins sicher nicht :-) Im Konsumer-Bereich will man die Firmware seines Receivers wohl auch eher über USB-Stick oder WLAN updaten. Wobei, stell ich mir lustig vor im Benutzerhandbuch: 1) Besorgen sie sich einen ATMEL Avr Dragon oder kompatibles Programmiergerät 2) Installieren Sie libUSB und avrdude 3) Verdrahten sie die Pins 1,2,3,4,5,6 der JTAG Schnittstelle mit den Pins 2, 4, 3, 1, 7, 8 des AVR Dragons 4) tippen sie in die Kommandozeile: avrdude -Pdragon_jtag... In welcher Branche bist du denn unterwegs dass dir Bootloader so fremd sind, wenn man fragen darf?
Ben schrieb: > In welcher Branche bist du denn unterwegs dass dir Bootloader so fremd > sind, wenn man fragen darf? In welcher Branche bist DU denn unterwegs, dass du so viel Wert auf eine Updatemöglichkeit legst? Wenn wir unsere Anlagen ausliefern, dann sind diese PERFEKT! Wir brauchen keine Updates und somit auch keinen Zugang dafür. Bei uns prüfen wir unser Tun selbst und lassen nicht unsere Kunden in die Scheisse fassen. Ulli-B
Leute, kommt mal wieder zurück. Da oben war gefragt worden, warum Hobbyanwender einen Bootloader statt JTAG bevorzugen.
Ulli-B schrieb: > Wenn wir unsere Anlagen ausliefern, dann sind diese PERFEKT! Wir > brauchen keine Updates und somit auch keinen Zugang dafür. und rechtfertigt das im Zweifel als Feature.
Ulli-B schrieb: > Wir > brauchen keine Updates und somit auch keinen Zugang dafür. Aber du gibst mir hoffentlich recht wenn ich sage, es ist besser etwas zu haben und nicht zu brauchen als anders herum?
Ulli-B schrieb: > PERFEKT Der war wirklich gut... Ausgereift mag ja sein, aber perfekt wage ich zu bezweifeln. Jeder der sich einen Zugriff auf seinen Controller so verbaut, dass er nicht mehr dran kommt ist selber Schuld.
Als besagter Hobbyanwender (und weil der Thread eh schon erstens beantwortet (danke nochmal) und zweitens derailed ist) kann ich Dir schon sagen, 'n Bootloader ist manchmal sehr praktisch. Erstens brauch ich nicht immer die ganze Programmierperipherie mitnehmen wenn ich beispielsweise irgendwo in der Pampa bei einem (beruflichen) Projekt sitze und am Abend noch was an meinem (privaten) Projekt machen will. Bootloader im µC der 'n Update über USB erlaubt und der Laptop + Ladekabel vom Handy ist alles was man braucht. Ja, für USB braucht's mehr als ein paar Kabel ins JTAG interface pappen, aber üblicherweise steckt der µC ja eh in seiner Schaltung und wenn die ohnehin 'n USB Interface hat... Zweitens war es recht amüsant und interessant den Bootloader zu entwickeln. Schon dabei hab ich viel gelernt, nicht nur über Bootloader selbst sondern auch über USB und wie man damit quasselt. Und drittens... najo, warum flog der Mensch auf'n Mond? Weil der Mond da ist und irgendwer gesagt hat "geht doch eh nicht".
Frank M. schrieb: > Anzahl der Threads, mit heutigen Beiträgen, Stand 13:45 Uhr: > > ARM 4 > AVR 5 > Arduino 2 > MSP430 1 > PIC 2 > Rest 0 > > Das ist jetzt sicherlich nicht repräsentativ. Aber mach das mal > regelmäßig für ARM und AVR. ARM holt hier immer mehr auf. "Statistik" ist ein anderes Wort für "Aberglaube". Deine Aufzählung kann bedeuten: 1. ARM-Anwender haben zunehmend Probleme mit diesen Dingern und suchen Hilfe 2. Die meisten Leute verwenden den AVR. 3. Arduino Anwender sind intellektuell minderbegabt und finden nicht mal dieses Forum. 4. MSP430 und PIC-Anwender meiden dieses Forum wegen des geistigen Dünschisses hier. 5. Der Rest hat soziale Probleme und trollt hier rum. Deine Statistik kann man auch ganz anders interpretieren. Wie es einem gerade gefällt, oder was man hinein interpretieren will.
Jörg Wunsch schrieb: > Da oben war gefragt worden, warum Hobbyanwender einen Bootloader > statt JTAG bevorzugen. Ganz einfach: Um so schöne kostenfreie Software wie Beitrag "UpdateLoader: Benutzeroberfläche für FastBoot AVR-Bootloader" zum drahtlosen Fernupdaten des AVRs verwenden zu können ;-)
Ben schrieb: > Steffen Rose schrieb: >> Ich arbeite beruflich mit den >> verschiedensten Prozessoren > > Steffen Rose schrieb: >> Was ist der Grund dafür, dass ein Bootloader gegenüber einem JTAG Zugang >> bevorzugt wird? > > Du machst das beruflich und kannst dir deine Frage nicht selbst > beantworten? Echt jetzt? > > Wie updatet ihr denn "draußen im Feld" die Firmware? Na ja, ich würde sagen der Bootloader kommt am Ende dazu, wenn das Produkt fertig entwickelt ist. Die 30-40€ die so ein Programmier- und Debug-Tool noch kostet ist mir die eingesparte Zeit schon Wert. Zum Entwickeln ist ein Bootloader eigentlich doch total unkomfortabel. (normaler Arbeitsplatz vorausgesetzt)
Volker SchK schrieb: > Zum Entwickeln ist ein Bootloader eigentlich doch total unkomfortabel. > (normaler Arbeitsplatz vorausgesetzt) Was an "draußen im Feld" hast du nicht verstanden? Tipp: "Laborarbeitsplatz während der Entwicklung" != "draußen im Feld"
Ben schrieb: > Was an "draußen im Feld" hast du nicht verstanden? > Tipp: > "Laborarbeitsplatz während der Entwicklung" != "draußen im Feld" Was an Volker SchK schrieb: > Na ja, ich würde sagen der Bootloader kommt am Ende dazu, wenn das > Produkt fertig entwickelt ist. hast du nicht verstanden?
Jetzt beharkt Euch nicht wie Kleinkinder. Ich denke Ihr seid professionelle Entwickler... JTAG wie Debugging alles gut und schön, wenn man ernsthaften Fehlern auf den Grund gehen muß. Der Test des "bootgeloadete" Programm ist in echter Umgebung aber noch eine ganz andere Hausnummer. Bootloader sollten zur Pflichtausstattung jedes Controllers gehören.
Moby schrieb: > Bootloader sollten zur > Pflichtausstattung jedes Controllers gehören. Wieso? Den kann man ja im Gegensatz zu JTAG in Software nachrüsten falls nötig.
Feste Bootloader im ROM am besten. Kann man JTAG selber heute nicht schon veraltet nennen? Beim Xmega langt mir jedenfalls das 2+2 pinnige Debugging via PDI/AtmelICE vollkommen.
Ben schrieb: > Volker SchK schrieb: >> Zum Entwickeln ist ein Bootloader eigentlich doch total unkomfortabel. >> (normaler Arbeitsplatz vorausgesetzt) > > Was an "draußen im Feld" hast du nicht verstanden? > Tipp: > "Laborarbeitsplatz während der Entwicklung" != "draußen im Feld" Sorry, Bezog sich auf Heinz L. schrieb: > Erstens brauch ich nicht immer die ganze Programmierperipherie mitnehmen > wenn ich beispielsweise irgendwo in der Pampa bei einem (beruflichen) > Projekt sitze und am Abend noch was an meinem (privaten) Projekt machen > will. Bootloader im µC der 'n Update über USB erlaubt und der Laptop + > Ladekabel vom Handy ist alles was man braucht. Ja, für USB braucht's > mehr als ein paar Kabel ins JTAG interface pappen, aber üblicherweise > steckt der µC ja eh in seiner Schaltung und wenn die ohnehin 'n USB > Interface hat... So wenn ich mal mein Privatprojekt mit in den Urlaub genommen habe und mich abends im Zelt an meinem Notebook langwiele, weil gerade keine sinnlose Diskussion auf uC.Net läuft in der ich mich einbringen kann ...
Moby schrieb: > Kann man JTAG selber heute nicht schon veraltet nennen? Kann man nicht, weil das am eigentlichen Sinn von JTAG vorbeigehen würde. Debugging darüber ist ja eigentlich erstmal ein Nebeneffekt.
Jörg Wunsch schrieb: > Debugging darüber ist ja eigentlich erstmal ein Nebeneffekt. Wenn es dadurch günstige Debug-Tools gibt, dann ist es ja wenigstens ein angenehmer Nebeneffekt ;-)
Bootloader ist was fürs fertige Produkt. zB bei einem damaligen System mit AVR32: vorne auf die Front eine USB-B. Da liegt entweder die Schnittstelle zur Parametrierung als USB-CDC oder eben der Bootloader, damit man die Firmware, falls doch mal nötig, updaten kann, ohne das Board aus dem Schaltschrank zu puhlen. Während der Entwicklung hing das Teil aber kontinuierlich am Debugger. Wesentlich komfortabler. Und den Bootloader mit reinzupappen ist ja auch fast ein no-brainer. Bei größeren Prozessoren, die ein Betriebssystem haben, würde ich da eher eine USB-A spendieren, als "Service" gelabelt. Entweder der Techniker lädt sein Smartphone (und freut sich), oder der Kunde kann die Kiste mittels USB-Stick neu urladen. Dafür liegt halt eben der Bootloader im FlashROM (und wird vom normalen Update nie angefasst). Ein Bootloader kann (!) auch ein Linuxkernel mit initrd sein...
hansjörg schrieb: > Steffen Rose schrieb: >> Was ist der Grund dafür, dass ein Bootloader gegenüber einem JTAG Zugang >> bevorzugt wird? > > Ich vermute mal: USB-UART < 5€, JTAG sicher viel mehr. nicht wirklich, oder? Speziell ST ist günstig. Discovery-Kit für die STM32F0-Serie bei Conrad (nicht gerade ein billiger Anbieter) <15 Euro. Enthält u.a. den ST-Link. Dieser kann auch unabhängig vom Rest des Boards zum Flashen UND Debuggen eingesetzt werden. Ich glaub bei diesen Preisen kann es nicht daran liegen.
Ben schrieb: > Wie updatet ihr denn "draußen im Feld" die Firmware? Über das Bussystem, welches auch im Feld eingesetzt eingesetzt wird. Und damit fällt üblicherweise der CPU interne Bootloader weg. Außerdem benötigt man für die CPU internen Bootloader typischerweise Jumper oder ähnliches, um diese zu aktivieren. Ich gehe davon aus, dass die meisten Hobbiisten - und nur die habe ich mit der Frage angesprochen - keinen eigenen Bootloader entwickeln. Ich nehme auch mal an, möglicherweise fälschlich, dass hier viele der Hobbiisten nicht gerade die Elektronik so sehr verbauen, dass sie nicht mehr an die JTAG Anschlüsse kommen. Und an die UART Pins für den Bootloader müßte man auch ran. Ja, und im Feld gibt es auch noch die gewollte Zugangsbeschränkung, weshalb der JTAG abgeschaltet wird. Ansonsten gibt es noch Nadelkontakte, um auch später noch an den JTAG zu kommen. Aber das sehe ich für den Hobbybereich nicht so geeignet.
Ben schrieb: > In welcher Branche bist du denn unterwegs dass dir Bootloader so fremd > sind, wenn man fragen darf? Beruflich schreibe ich selbst Bootloader. Ist mir also nicht fremd. Aber warum so umständlich im *privat/hobby* Bereich? Man hat ja keine größeren Stückzahlen zu flashen. Also kann man gleich mit der Entwicklungsumgebung flashen. Ein extra Flashtool wird im Hobbybereich also nicht benötigt. Außer evtl., wenn man hex-Files mit der Comunity austauschen will. Vermutlich wird auch beim Hobby auch direkt auf der Zielhardware entwickelt. Auch hierfür wäre der JTAG super geeignet.
Heinz L. schrieb: > Als besagter Hobbyanwender (und weil der Thread eh schon erstens > beantwortet (danke nochmal) und zweitens derailed ist) kann ich Dir > schon sagen, 'n Bootloader ist manchmal sehr praktisch. Danke. Das war eine der Antworten, die mich interessiert hat.
Moby schrieb: > Feste Bootloader im ROM am besten. > Kann man JTAG selber heute nicht schon veraltet nennen? > Beim Xmega langt mir jedenfalls das 2+2 pinnige Debugging via > PDI/AtmelICE vollkommen. Für SWD am ARM brauchts auch nicht gerade viel.
Steffen Rose schrieb: > Moby schrieb: >> Feste Bootloader im ROM am besten. >> Kann man JTAG selber heute nicht schon veraltet nennen? >> Beim Xmega langt mir jedenfalls das 2+2 pinnige Debugging via >> PDI/AtmelICE vollkommen. > > Für SWD am ARM brauchts auch nicht gerade viel. Und wen überrascht es jetzt, dass der Herr Obertroll sein Hassobjekt noch nicht einmal im Ansatz kennt? Sorry, aber AVR hat ausgedient. STM32 und seine Kollegen sind genauso einfach zu handhaben (Em:Blocks ist einfach angenehmer als dieser AVR Studio Kram), billiger. Und die Hardwareschicht programmiert man für jeden Controller nur einmal. Meine Initialisierung hat in der Anwendung pro Peripherie genau eine Zeile. Abstrahierung und Standardisierung macht es möglich. Klar, die Performance braucht man nicht, aber wenn ein Controller billiger, leistungsfähiger, einfacher und sparsamer ist, was spricht dagegen? Da kann ich auch eine Menge Rechenleistung in Diagnose und Berechnung per Float verschwenden, das macht mir das Leben viel leichter. Das einzige was für AVR spricht ist die Verfügbarkeit in DIP. Aber wenn ich etwas in Lochraster baue, nehme ich gleich ein ganzes Discovery Kit. Das ist einfacher, weil Debugging inklusive. Steffen Rose schrieb: > Über das Bussystem, welches auch im Feld eingesetzt eingesetzt wird. Und > damit fällt üblicherweise der CPU interne Bootloader weg. Außerdem > benötigt man für die CPU internen Bootloader typischerweise Jumper oder > ähnliches, um diese zu aktivieren. Ich kenne es auch nicht anders. Interner Bootloader ist ziemlich unnötig. Während der Fertigung wird eh ein In-Circuit-Test gemacht, da wird auch gleichzeitig der Bootloader und bei Bedarf die Applikation aufgespielt.
Antimedial schrieb: > das macht mir das Leben viel leichter. Jaja, du redest von einem ziemlich hohen Roß herunter. Nun, in vielen Dingen sehe ich es ja ähnlich wie du - und wir sehen seit etwa 2 Jahren, wie die Cortexe den Rest im Aquarium auffressen, obwohl es manche nicht wahrhaben wollen. Aber der Thread geht um's Basteln. Man kann sich durchaus in verschiedenen Abständen zur Hardware positionieren, im Extremfall die Dinge nur aus der Sicht des BWL'lers sehen und die Details den Anderen überlassen - insbesondere die technischen Details. Im Gegensatz zu dir bin ich durchaus ein Freund von fest im Chip vorhandenen Bootladern. Wer sie nicht braucht, braucht sie nicht zu benutzen, wer aber als Bastler mit seinem Taschengeld haushalten muß, für den ist sowas segensreich. Das Allereffektivste beim Anwenden von µC ist jedoch, ein Pflichtenheft aufzusetzen und das ganze einem Ingenieurbüro zur Erledigung zu geben und bis zur Erledigung sich um was Anderes zu kümmern. Null eigener Handschlag bis zum Verkaufsstart - mal abgesehen von den Händedrücken beim Arbeitsessen... Nun ja - wenn ich deine Worte mal extrapoliere, dann kommt dabei "Raspberry" heraus. Das braucht man noch nicht einmal auf ein Steckbrett zu stopfen, denn es gibt ja Gehäuse dafür. Und dem Interessenbereich des TO wäre so ein Raspberry wohl auch eher angemessen: Heinz L. schrieb: > Was mich in Zukunft interessieren wird ist vor allem Vernetzung und > WPAN/WBAN. Sieht unheimlich interessant aus, nur hab ich damit noch > herzlich wenig zu tun gehabt Tja. WPAN/WBAN Nen schönen Abend noch, W.S.
Antimedial schrieb: > Und wen überrascht es jetzt, dass der Herr Obertroll Auf Trolle reagiert man nicht jahrelang ohne Unterlass- auf Obertrolle schon mal gleich gar nicht! > Sorry, aber AVR hat ausgedient. Diese Deine ebensolang vertretene Meinung überrascht nun auch nicht gerade. > STM32 und seine Kollegen sind genauso > einfach zu handhaben (Em:Blocks ist einfach angenehmer als dieser AVR > Studio Kram), billiger. Und die Hardwareschicht programmiert man für > jeden Controller nur einmal. Meine Initialisierung hat in der Anwendung > pro Peripherie genau eine Zeile. Abstrahierung und Standardisierung > macht es möglich. Ja, das ist eben der Unterschied: Bei STM32 und Kollegen braucht es fast zwingend Hardwareschicht und Abstraktion (verpackt in jeder Menge Libs), um deren Komplexität einigermaßen zu zähmen. Bei SimplyAVR können diese Begrifflichkeiten dagegen gut und gerne Fremdworte bleiben! > Das einzige was für AVR spricht ist die Verfügbarkeit in DIP. Oh, hat der Herr doch noch einen Vorteil ausgemacht... Erst gestern habe ich mich für ein neues Projekt gegen den Xmega und für einen bewährten Mega88 entschieden: Damit sich nämlich ein billiger MOSFET simpel ansteuern lässt. Der große Einsatzbereich der ausgereiften guten alten AVRs ab 1,8V aufwärts bis 5V ist eben immer wieder von Vorteil ;-) > nehme ich gleich ein ganzes Discovery Kit. > Das ist einfacher, weil Debugging inklusive. Und ich bleibe stets bei der praktischen Winzigkeit einzelner Chips und optimalem Anwendungsdesign. Aber wer Platz und Strom im Überfluß hat.. > Ich kenne es auch nicht anders. Interner Bootloader ist ziemlich > unnötig. Na für Dich vielleicht. Der flexible Hobbybastler hingegen programmiert sein Projekt drahtlos und in echter Umgebung. Mit viel frei verfügbarer Software (z.B. siehe weiter oben). Es braucht dank der einfachen Struktur der AVRs auch nicht dieses intensive Debugging ;-)
Heinz L. schrieb: > Was mich in Zukunft interessieren wird ist vor allem Vernetzung und > WPAN/WBAN. Sieht unheimlich interessant aus, nur hab ich damit noch Ich hab mir von der Embedded World ein Experimentierboard mit gebracht. Ein Chip mit eingebautem IEEE 802.15.4 und Lo6WPAN Protokoll Software. Der Hersteller pappt den Chip zusammen mit der Antenne auf ein etwa 2x3cm Platinchen. Am Rand der Platine sind Löt-Pads im 1.27 mm Raster. Da kann man das dann auf seine Bastelplatine auflöten. Stückzahlpreis 7 EUR. Allerdings ist die Reichweite nicht so super. Man könnte aber noch ne externe Antenne draufclipsen. Ist nen Cortex M4 drinnen. Was derartiges würde ich auch nicht mehr auf nem AVR machen. Ist ja immerhin alles IPv6 basiert. Ich nutze AVRs gerne wenss aufs Timing ankommt, für kleine Dinge sowieso. Man kann das ziemlich gut Berechnen. Beim ARM macht einem da die Pipeline schwierigkeiten. MP3 Dekodieren dagegen... Klar kann man einen extern Chip dafür an den AVR pappen. Für den Preis bekommen ich dann aber auch als Bastler mindestens 2 Arme. Es ist im übrigen völliger Unsinn, das C++ bzw OOP Leistung verschwendet. Vielmehr erlaubt es eine vielfach bessere Wiederverwertbarkeit von Code. Man denke nur an Templates & Co. Man muss halt nur wissen was man tut. Z.b. transparent auf eeprom/flash zugreifen:
1 | #if defined(USE_FLASH)
|
2 | static FlashVariable<uint8_t> myvar PROGMEM = {10}; |
3 | #elif defined(USE_EEPROM)
|
4 | static EEVariable<uint8_t> myvar EEMEM = {10}; |
5 | #elif defined(USE_RAM)
|
6 | static uint8_t myvar = 10; |
7 | #endif
|
8 | |
9 | void main() |
10 | {
|
11 | uint8_t x = myvar; /* I don't care where myvar is stored */ |
12 | myvar = 5; /* store in eeprom or flash or ram*/ |
13 | }
|
Moby schrieb: > einfachen Struktur der AVRs Einfach? Früher als man noch alles mit NAND aufgebaut hat, das war einfach:
1 | A B | Y |
2 | -----|--- |
3 | 0 0 | 1 |
4 | 0 1 | 1 |
5 | 1 0 | 1 |
6 | 1 1 | 0 |
und das war‘s auch schon. Begrifflichkeiten wie Assembler, Bootloader, Debugger... konnten gut und gerne Fremdworte bleiben
:
Bearbeitet durch Moderator
Moby schrieb: > Bei STM32 und Kollegen braucht es fast zwingend Hardwareschicht und > Abstraktion (verpackt in jeder Menge Libs) Humbug.
1 | #include "sam.h" |
2 | |
3 | void _init(void) |
4 | {
|
5 | }
|
6 | |
7 | int
|
8 | main(void) |
9 | {
|
10 | PM->APBBMASK.reg = 8; |
11 | |
12 | /* PA19: input with pulldown */
|
13 | PORT->Group[0].PINCFG[19].bit.INEN = 1; |
14 | PORT->Group[0].PINCFG[19].bit.PULLEN = 1; |
15 | PORT->Group[0].OUTCLR.bit.OUTCLR = (1 << 19); |
16 | |
17 | /* PA16: input with pullup */
|
18 | PORT->Group[0].PINCFG[16].bit.INEN = 1; |
19 | PORT->Group[0].PINCFG[16].bit.PULLEN = 1; |
20 | PORT->Group[0].OUTSET.bit.OUTSET = (1 << 16); |
21 | |
22 | /* LED0 on XPlainedPro: PB30, active low */
|
23 | PORT->Group[1].DIRSET.bit.DIRSET = (1 << 30); |
24 | PORT->Group[1].OUTSET.bit.OUTSET = (1 << 30); |
Das ist die komplette Initialisierung eines SAMD20 (Cortex-M0+), um einen Pin auf Input mit Pullup, einen auf Input mit Pulldown und einen auf Ausgang (LED) zu setzen. Auf das Einstellen irgendeines speziellen Taktgenerators wurde verzichtet, braucht man hier nicht. Das würde bei einem Xmega auch kaum anders aussehen:
1 | #include <avr/io.h> |
2 | |
3 | int
|
4 | main(void) |
5 | {
|
6 | /* PA4: input with pullup */
|
7 | PORTA.PIN4CTRL = PORT_OPC_PULLUP_gc; |
8 | |
9 | /* PA5: input with pulldown */
|
10 | PORTA.PIN5CTRL = PORT_OPC_PULLDOWN_gc; |
11 | |
12 | /* PB1: output, input disabled, default high */
|
13 | PORTB.PIN1CTRL = PORT_ISC_INPUT_DISABLE_gc; |
14 | PORTB.DIRSET = (1 << 1); |
15 | PORTB.OUTSET = (1 << 1); |
Der größte Unterschied ist noch, dass man beim SAMD20 den Takt für die PORTs erstmal einschalten muss, aber andere ARMs haben bspw. den Takt für die PORTs standardmäßig an. Dafür müsste man eigentlich beim Xmega dann noch hingehen und den Takt für die vielen nicht genutzten Baugruppen ausschalten, um sinnlosen Stromverbrauch zu vermeiden.
:
Bearbeitet durch Moderator
Es heisst eben die optimalen Mittel für die Anwendung finden. Der AVR passt da meistens. Extreme aber sind immer schlecht ;-)
Andreas Messer schrieb: > Was derartiges würde ich auch nicht mehr auf nem AVR machen. Ist ja > immerhin alles IPv6 basiert. Kein Argument. Schließlich macht man mit den 128-bit-IPv6-Adressen ja keine Arithmetik. ;-) 6LowPAN haben sie seinerzeit noch mit ATmega128 angefangen, und ein Modul mit ATmega256RFR2 ist auch nicht größer als die von dir genannten und genauso gut in der Lage, dein 6LowPAN zu beherbergen. ZigBee Lightlink könnte sogar noch komplexer sein in dieser Hinsicht, und das wiederum wird damit gemacht. Nein, dort ist die MCU-Architektur nahezu egal. Wie du schon schreibst, ein MP3-Player ist was anderes dagegen.
Steffen Rose schrieb: > Was ist der Grund dafür, dass ein Bootloader gegenüber einem JTAG Zugang > bevorzugt wird? Wenn man eine Firmware nicht mit einem Klick auf "Upload" in der Arduino IDE hochladen kann, hat man bei einem Open Source Projekt 90% der potentiellen Benutzer aussen vor. Selbst so ein 20-Euro Programmieradapter für ISP ist schon zu kompliziert. Deswegen wurden die Bootloader ja überhaupt erst eingeführt. Wobei ich offengestanden keine Ahnung habe, wie das mit dem JTAG funktioniert. Bin jetzt 3 Jahre dabei und habe das noch nie gebraucht.
Moby schrieb im Beitrag #4094688: > Dir fällt aber schon auf das selbst diese kleine Funktionalität bei > Xmega deutlich kürzer daherkommt? Nein, von „deutlich“ kann da keine Rede sein. Es sind halt ein paar Designentscheidungen bei diesem ARM anders getroffen worden (PIO nicht standardmäßig getaktet, Input-Treiber nicht standardmäßig aktiv), aber das hat nichts mit ARM an sich zu tun. Schon beim SAM3 aus dem gleichen Hause wäre das anders. (Wenn du bei jedem Projekt mit einem AVR alle nicht genutzte Funktionalität wie Clocks und Input-Treiber sauber abschaltest, dann wird der plötzlich „deutlich komplexer“.) Das Beispiel sollte aber vor allem deine Behauptung widerlegen, dass man erst „tonnenweise Libs“ bräuchte, bevor man mit einem ARM was machen kann. Dem ist nicht so, das Ding läuft auch einfach erstmal los und kann aus der Dose raus arbeiten, wie jeder andere Controller auch. Dass mehr Möglichkeiten in der Hardware auch dickere Handbücher zur Folge haben, hat nun überhaupt nichts mit 8-bit vs. 32-bit zu tun: schau dir das Datenblatt eines AT90S8535 an, vergleich es mit es mit einem ATmega16 (pinkompatibler Nachfolger), dann mit einem ATmega324P (auch pinkompatibler Nachfolger), und sieh dir dann an, wieviel mehr man selbst an einem Xmega schon typisch rumfummelt, bevor es richtig losgeht. Aber das ist auch jeweils nur normaler technischer Fortschritt, die jeweiligen Nachfolger haben auch da oft bereits weniger gekostet als die, die sie abgelöst haben.
:
Bearbeitet durch Moderator
Ich hatte nun keine Zeit, leider, um alle Kommentare zu lesen, da ich diesen Beitrag von der Arbeit aus schicke und gleich weiter machen muss. Ich finde deine Frage sehr, sehr berechtigt, und kann aus meiner eigenen Erfahrung ein bisschen was dazu sagen. Während meines Master-Studiums habe ich zum ersten Mal mit einem 32-bit MCU gearbeitet, nämlich dem STM32F407. Es handelte sich um eine Studienarbeit im Rahmen der Rehabilitation-Robotik, also um Echtzeitverarbeitung von kinematischen Daten, die an einem Knie-Exoskeleton während des Laufens gemessen wurden. Den Exoskeleton haben wir anhand von Simulink Real-Time geregelt, wobei die Messungen und Kommunikation zwischen eingebetteter Elektronik und SLRT vom erwähnten MCU übernommen wurde. Die Anforderungen an der Genauigkeit und Baud-Rate der seriellen Kommunikation und ADC-Wandlung wareun deshalb, aus dem Grund weil es eine medizintechnische Anwendung ist, sehr hoch. Mir kam es zunächst komisch vor, dass man mir gleich einen solchen ARM Cortex M4 in die Hand gegeben hat, im Laufe des Projekts habe ich es dann aber aus den vorher erwähnten Gründen völlig nachvollzogen, warum es so mächtig sein musste. Aber hier der Nachteil: die sind um Welten und Universen schwieriger zu durchblicken und zu programmieren, also ich kann nicht genug betonen, wie viel schwerer es ist, mit ihnen zu arbeiten. Du brauchst nur einen Blick auf die Feature-Seite des Datenblatts zu werfen und die Länge der RefMans anzuschauen, um dir eine Idee davon zu machen. Nun absolviere ich ein Praktikum und arbeite wieder mit eingebetteter Elektronik, diesmal aber am Bereich der Energietechnik, bei einer Anwendung, wo die Elektronik, die in IP66-Kisten zugeschlossen ist, Temperaturen bis zu 70°C ausgesetzt ist. Und aus welchem magischen Grund auch immer haben meine Vorgänger diese Elektronik mit ATTiny88s ausgestattet, und mit "magischem Grund" meine ich natürlich Kosten. Als wir einen Erwärmungsversuch ausgeführt haben, kannst du dir Vorstellen, was für ein Desaster das war. Die Kommunikation erfolgt über ein manuell als bit-banging programmiertes Modbus, da dieser MCU kein UART-Modul hat, und nicht nur während des Versuchs, sondern jetzt noch, nachdem wir die Kiste schon seit Wochen vom Labor zurückgebracht haben, geht mit der Hälfte der Mikrocontroller keine Kommunikation mehr, nicht mal mit Kalibrierung des internen Oszillators, obwohl sie ihre Funktionsweise sonst erhalten haben. Ihre Takt-Genauigkeit scheint permanent verloren zu sein. Hier geht sogar eine Frage: hat das jemand schon mal gehabt, dass nach solchen extremen Temperaturen das Ding permanent nicht mehr richtig taktet? Also als Fazit: für grosse, Leistungskritische Projekte, die streng genormt sind, wie z.B. Medizin- und Energietechnik, sollte man überall, nur nicht an Mikrocontrollern sparen. Wenn die nicht mehr richtig takten, hast du einen kompletten Albtraum am Debuggen der Kommunikation. Und trotz Z-Dioden und Kondensatoren und sonstigen elektrischen Schutz, sind 8-Bit MCUs einfach nur unzuverlässig, wenn du in der Prototypenphase mal öfters ein- und ausstecken musst - nichts, was du nicht wahrscheinlich schon weisst, wenn du solche Fragen stellst. Mit 32-Bit MCUs hast du das Problem ganz einfach nicht. Der Nachteil ist, dass es dein Leben unglaublich schwerer macht, mit den 32-Bit MCUs umzugehen, vor allem, was die Programmierung angeht. Entweder programmierst du blind mit Libraries vom Hersteller und kümmerst dich um die Funktionsweise der Registers usw nicht, oder viel Spass beim Lesen von 1700 Seiten im RefManual. Ich empfehle, wie in einem früheren Beitrag von jemandem anderen schon geschrieben, auch irgend einen Eval-Board, oder so ein Break-Out wie der STM32F407DISCOVERY, z.B. Cheers
Marc O.S. schrieb: > Der Nachteil ist, dass es dein Leben unglaublich schwerer macht, mit den > 32-Bit MCUs umzugehen, vor allem, was die Programmierung angeht. > Entweder programmierst du blind mit Libraries vom Hersteller und > kümmerst dich um die Funktionsweise der Registers usw nicht, oder viel > Spass beim Lesen von 1700 Seiten im RefManual. Was ich nie verstanden habe, ist, warum die Leute meinen, ein Referenzhandbuch komplett durchlesen zu müssen. Man pickt sich dort nur die Sachen heraus, die man benötigt. Ich habe schon bei den AVRs nie die gesamte Referenz durchgelesen, schlicht weil ich nie alle Hardware in den Dingern verwendet habe. Vom RefManual des STM32F4xx kenne ich bisher vielleicht 300 Seiten - den Rest lese ich erst dann, wenn ich ihn auch benötige. Wenn man natürlich nur die Featureliste eines 439 liest und denkt: "Oh Gott - was kann der denn nicht?", dann macht man sich das leben unnötig schwer. Die einzelnen Kapitelumfänge unterscheiden sich meist nicht großartig von denen der AVRs, nur die Anzahl der Kapitel ist deutlich größer. Für denjenigen, der eine bestimmte Eigenschaft benötigt, ist der Unterschied nur marginal.
Marc O.S. schrieb: > Also als Fazit: für grosse, Leistungskritische Projekte, die streng > genormt sind, wie z.B. Medizin- und Energietechnik, sollte man überall, > nur nicht an Mikrocontrollern sparen. Was natürlich für den hier fragenden TO als Hobbybastler ein wichtiges Kriterium ist ;) Für den (und genauso für mich) ist wichtig, daß es für Endverbraucher verfügbare Boards mit passender Bestückung zu kleinem Preis gibt. Ansonasten stimme ich dir zu, lieber gleich einen dicken Prozessor. > Wenn die nicht mehr richtig > takten, hast du einen kompletten Albtraum am Debuggen der Kommunikation. Das hat aber nichts mit klein oder groß zu tun. Falsches Soft.- und Hardwaredesign bzw. ignorieren der Datenblattwerte ist bei keinem Prozessor eine gute Idee. > Und trotz Z-Dioden und Kondensatoren und sonstigen elektrischen Schutz, > sind 8-Bit MCUs einfach nur unzuverlässig, wenn du in der > Prototypenphase mal öfters ein- und ausstecken musst - nichts, was du > nicht wahrscheinlich schon weisst, wenn du solche Fragen stellst. Mit > 32-Bit MCUs hast du das Problem ganz einfach nicht. Na ja, das ist so pauschal Unsinn. Oliver
Marc O.S. schrieb: > Ihre Takt-Genauigkeit scheint permanent verloren > zu sein. Ich würde daraus folgern, dass das Ding einen Quarz braucht.
ich habe ASM auf einem 68xx ... auf AVR 8bittern C gelernt .. so richtig C .. davor nur am PC .. ( studiumspielerei) dann etwas C++ ... womit ICH abernicht richtig warm werde ... Ist irgendwie nicht meine welt ... meine erfahrungen waren: AVR auch etwas komplizierte sachen wie SPI/I2C usw sind auf einem AVR unkompliziert und einfach in betrieb zu nehmen. ABER: einzig bei höheren Baudraten mit sehr viel ASCII-verarbeitung bekam ich so meine ersten probleme ... also peripherie gut und einfach ... aber beim zusammenspiel von viel peripherie und sehr viel verarbeitung hackte es immer irgendwo ARM M0/M3 interne peripherie ist von µC zu µC unterschiedlich und doch jedesmal kompliziert in der verwendnung wie oft man da erstmal sitzt und sich fragt warum der sch*** nicht geht ... unglaublich .. da helfen auch keine CMSIS dinger ABER : wenn die peripherie mal läuft !! .. ist die verarbeitung scheinbar deutlich leichter durch prioritäten und auch brauchbar gutmütigen RTOS'en klappen auch zig komplexe scheinbar endlose funktionen nun ist es so das der Bastler und auch der berufsprogrammierer sich diverse dinge vereinfacht Hat man mal diverse peripherie genutzt .. ist das alles nur halb so schlimm man hat codefetzen die zumindest erstmal funktionieren ( ob .lib oder fetzen ist dabei egal ) aber das schöne am ARM finde ICH : man KANN auch mit code rumquasen ... also auch mal uneffizient programmieren. das ist alles undramatisch und das gefällt mir auch so verwenden wir hier zB beides .. AVR und ARM wobei in zukunft eher ARM M0 einzug halten wird einzig aus einem Grund ... der STM32F030(32k) ist halb so teuer wie der ATmega88(8k)
web schrieb: > also peripherie gut und einfach ... aber beim zusammenspiel von viel > peripherie und sehr viel verarbeitung hackte es immer irgendwo Klingt nach Layer-8 Problem. Du hast dir vorrab keine Gedanken gemacht und einfach hingepfuscht. Beim viel schnelleren Cortex wurden auftretene Events (UART, ADC, was-auch-immer) schnell genug abgearbeitet so dass du dir über Synchronisation etc. weiterhin keine Gedanken machen brauchst. Dann geht eben kein Timerinterrupt mehr verloren weil du im UART-Interrupt den Kommandostring mittels strtok zerlegst.
Zurück zur eigentlichen Frage: Also, mir hat bis jetzt immer ein AVR gereicht. Der hat super Tools, wird gut vom Hersteller unterstützt, das Datenblatt ist kurz und übersichtlich. Klar, ab und zu brauch es noch etwas Peripherie. Z.B. ein ENC28J60 für Ethernet. Ein uM-FPU als Floating Point Coprozessor hat mir auch schon gute Dienste geleistet. Interface mit meinen heiß geliebten AVRs natürlich über SPI. Natürlich programmiere ich die AVRs nur in Assembler, damit ich die höchste Effizienz habe. Nicht so einen schrottigen C-Compiler, der doch ab und zu mal ein paar Taktzyklen verschenkt. Deshalb brauche ich keinen größeren Prozessor. Es wurde in letzter Zeit viel brauchbare Zusatzperipherie für meinen AVR entwickelt. Als Displayinterface habe ich schon ein STM32F429 Discovery verwendet. Ich kommuniziere per UART damit. Auf dem Discovery läuft eine Art Grafik-Server, irgend etwas mit qt5 embedded. Super als Zusatzplatine ist auch ein RaspberryPi. Der bringt eine schöne HDMI und eine Netzwerkschnittstelle mit. Auf dem RPi laufen dann Programme in Python, die die Daten übers Netzwerk annehmen, per UART an meinen AVR senden und dort wirds dann ich hocheffizentem Assembler verarbeitet. Gut, ich musste eine 512kB SRAM an meinen AVR anschließen, das war aber per Banking und Assembler kein Problem. Zur Ausgabe schicke ich die Daten dann wieder per UART an den RPi. Dort nimmt die Daten ein Python Skript entgegen und stellt sie via HDMI da. Alles kein Problem! Einmal war als kleine Erweiterung auch ein embedded PC Board vorgesehen. Dort wurden dann, so als Coprozessor für den AVR, Daten per Matlab weiterverarbeitet. Aber der AVR hat sie per 10 Bit AD-Wandler aufgenommen und auf einem 2x16 Zeichen LCD dargestellt. Da seht ihr mal, das ein AVR wirklich alles kann. Ich verstehe gar nicht, wie andere immer nach größeren Prozessoren schreien. Vermutlich können die alle kein Assembler, können nicht effizient programmieren. Ok, den Coprozessor mit Matlab habe ich in Auftrag gegeben, habe mir quasi eine IP-Core eingekauft, bin in Matlab nicht so fit. Wird woanders ja auch gemacht. Aber die AVRs reicht wirklich (mit ein bisschen Peripherie) für alles aus, wenn man sie ordentlich in Assembler programmiert!
Markus H. schrieb: > Marc O.S. schrieb: >> Ihre Takt-Genauigkeit scheint permanent verloren >> zu sein. > > Ich würde daraus folgern, dass das Ding einen Quarz braucht. und Oliver S. schrieb: >> Wenn die nicht mehr richtig >> takten, hast du einen kompletten Albtraum am Debuggen der Kommunikation. > > Das hat aber nichts mit klein oder groß zu tun. Falsches Soft.- und > Hardwaredesign bzw. ignorieren der Datenblattwerte ist bei keinem > Prozessor eine gute Idee. Na klar, ich führe ja Tests durch mit einem Design, das von Vorgängern erstellt wurde. Sie dachten, nachdem die MCUs abgekühlt sind, dass der interne Taktgeber wieder normalisiert, auch wenn er während der hohen Temperaturen von der Kalibrierung abweicht. Das ist aber wider Erwartungen nicht der Fall, nicht mal nachdem man sie wieder Kalibriert. Es gehört ja zu meinen Aufgaben, Kosten- und Leistungsoptimierung vorzunehmen. Die Frage war, ob jemand diese permanente Störung des internen Taktgebers schon erlebt hat, nur zur Info. Ansonsten war der Grund, aus dem ich das erwähnt habe, einfach die Beantwortung der ursprünglichen Frage, ob kleine Mikrocontroller für grosse Projekte taugen - tun sie meiner Ansicht nach eben nicht. Ein externer Quarz würde sicherlich helfen, allerdings wäre es schon ein Traum, wenn das das einzige Problem wäre, das ich erlebt habe. Aber hier kann man natürlich einfach mit einem besseren 8-Bit Mikrocontroller oder mit einem 16-Bit Mikrocontroller arbeiten, 32-Bit MCUs wären vllt. schon overkill. Oliver S. schrieb: > Na ja, das ist so pauschal Unsinn. War ja ne ziemliche Verallgemeinerung, aber spürbar stabiler und robuster sind sie nach meiner Erfahrung eigtl. schon. Chris D. schrieb: > Vom RefManual des STM32F4xx kenne ich bisher vielleicht 300 Seiten - den > Rest lese ich erst dann, wenn ich ihn auch benötige. > > Wenn man natürlich nur die Featureliste eines 439 liest und denkt: "Oh > Gott - was kann der denn nicht?", dann macht man sich das leben unnötig > schwer. Kuck mal was der schrieb: web schrieb: > aber beim zusammenspiel von viel > peripherie und sehr viel verarbeitung hackte es immer irgendwo Genau das habe ich eigtl. gemeint. Wenn man, wie es in meinem und in seinem Fall anscheinend passiert ist, viele Peripheriefunktionen gleichzeitig benutzt, und nicht nur einen kleineren Teil der verfügbaren Funktionaliät, und diese Peripherien aufgrund der enormen Komplexität des MCU sehr genau miteinander eingestellt und abgestimmt werden müssen, dann wird der Aufwand schon sehr hoch und die Zeit beim Lesen von länglichen RefMans schon erheblich höher als man mit einem 8-Bit MCU normalerweise braucht. Die Dinger können zum Teil parallele Threads ausführen und alles über DMA im Hintergrund laufen lassen, um nur ein paar grössere Fähigkeiten zu erwähnen, die das korrekte Programmieren schnell kompliziert machen können. Wiederhole: bei grösseren Projekten, die den 32-Bit MCU selbst auslasten. Es ist nur zusätzliche Information für die ursprüngliche Frage unseres Kollegen: reichen 8-Bit MCUs aus wenn es richtig zur Sache geht? Manchmal eben nicht. Aber man kann ja immer 32-Bit MCUs zu 10% auslasten, wo 8-Bit MCUs reichen würden, und man kann 8-Bit MCUs unzuverlässig betreiben, wo mehr Power den Anforderungen locker geüngen würden, aber oft mit grösserem Programmieraufwand. Für jeden Fall gibt es eine optimale Lösung, es ist ja nicht so, als würden 32-Bit MCUs das Ende der 8-Bit MCUs herbeirufen, oder?
Moby schrieb: > Es heisst eben die optimalen Mittel für die Anwendung finden. Der AVR > passt da meistens. Extreme aber sind immer schlecht ;-) Extrem wäre wohl Cortex-A9 oder so. Für einen Vergleich mit dem AVR ist aber eher der Cortex-M0 sinnvoll. Moby schrieb im Beitrag #4094659: > hansjörg schrieb: >> Moby schrieb: >> Der AVR passt da meistens. >> >> Ein ARM auch. > > Selbst wenn: DAS allein wäre für die Umstiegsmotivation etwas dürftig > ;-) Warum? Ich denke hier speziell an das Argument, dass man immer etwas neues lernen will und der Weg das Ziel ist. Moby schrieb im Beitrag #4094688: > Es ist doch einfach nur albern, die klar einfachere Struktur der AVRs > beständig zu bestreiten. Obwohl ich ARM Beführworter bin, hast Du in diesem Punkt recht. Obwohl der ARM hier schon mehrfach schwerer dargestellt wird, als er wirklich ist. Zumindest, wenn man bei der üblcihen Standardfunktionalität bleibt.
Marc O.S. schrieb: > War ja ne ziemliche Verallgemeinerung, aber spürbar stabiler und > robuster sind sie nach meiner Erfahrung eigtl. schon. 1. Man kann nicht vergleichen, wenn man 2 verschiedene Bedingungen hat. Um das zu können müsstest du mit dem 8bitter die Aufgabe des ARM und anders rum lösen. Wer sagt denn, dass sich bei 70°C nicht auch der ARM verabschiedet? Wenn man einen nimmt, der bis 85°C spezifiziert ist, wäre das, abhängig von der verbratenen Leistung und dem Rth,j nichtmal so unwahrscheinlich. 2. Ist es nicht Sinnvoll von einem Fall eines 8bitters auf alle zu schließen. Du sagst quasi aus, dass alle AVR, (8bit)PICs, 8081, 8085, EFM8,... weniger stabil und zuverlässig sind, als alle ARMs, MIPS, .. Da bezweifle ich aber, dass du das beurteilen kannst und dass es so stimmt. Marc O.S. schrieb: > Sie dachten, nachdem die MCUs abgekühlt sind, dass der > interne Taktgeber wieder normalisiert, auch wenn er während der hohen > Temperaturen von der Kalibrierung abweicht. Wenn man ihn aber durch z.b. zu hohe Temperatur grillt nicht. Genauso ist er kaputt, wenn du 40V anlegst, auch wenn du ihn danach wieder mit 3,3V betreibst. Marc O.S. schrieb: > Ansonsten war der > Grund, aus dem ich das erwähnt habe, einfach die Beantwortung der > ursprünglichen Frage, ob kleine Mikrocontroller für grosse Projekte > taugen - tun sie meiner Ansicht nach eben nicht. Das bspw. ARMs Leistungsfähiger als bspw AVRs dürfte bekannt sein. Die Frage ist nur, was ist ein großes Projekt? Eine HD Videoanzeige auf einem FullHD Fernseher via HDMI? Dann gebe ich dir recht. Ein GPS-Logger, der die gespeicherten Daten via USB an den PC sendet? Oder ein kleiner Web-Server um zu gucken, ob und welche Lichter im Haus noch an sind? Dann würde ich dir widersprechen. Ich hab das Gefühl, dass die Beurteilung eines großen Projekts immer mehr abdriftet. Durch den niedrigen Preis macht es ja meist kaum einen Unterschied. Aber komisch finde ich es schon, was alles ach so kompliziert und groß ist, wo unbedingt ein M4 oder gar RasPi her muss. Wenn man mal bedenkt, dass die neuen PIC32MZ 2MB Flash haben...Da brauch ich dann 4 Stück, damit meine Taschenlampenapp drauf passt, um die LED vom Handy anzumachen. ;)
Oliver S. schrieb: > Was natürlich für den hier fragenden TO als Hobbybastler ein wichtiges > Kriterium ist ;) Als Hobbybastler hat man doch eh alle Möglichkeiten. Man kann auch den AVR für größere Projekte nehmen und wenn man irgendwann feststellt, dass der nicht ausreicht, wechselt man eben oder lässt das Projekt sterben, wenn man keine Lust an etwas neuem hat. Oder man macht gleich nur Projekte, für die AVR auf jeden Fall reicht. Oder man nimmt gleich immer den ARM und macht sich keine Gedanken mehr über Ressourcen. Wenn der M0 nicht reicht geht man ohne große Schwierigkeiten auf den M4. Oder man nimmt gleich ein Raspberry Pi und bastelt damit herum. Beim Hobby geht es um den Weg nicht um das Ziel. Wer mehr Spaß an Assemblerbastlei hat, soll dabei bleiben. Manche Leute basteln auch erst im FPGA ihren eigenen Prozessor und programmieren den dann. Auch wenn das Ding hinterher weniger kann als ein 40 Jahre alter 4-bitter. Nur wird derjenige kaum versuchen, allen Leuten ihr Werk anderen für echte Projekte anzudrehen, auch wenn sie sicherlich stolz auf ihre Leistung sein können. Wenn man "einfach" für Bastler definieren will, dann die Lösung mit dem geringsten Einarbeitungsaufwand von 0. Da ist Arduino, Raspberry Pi vorne, dann C auf ARM und AVR, Assembler kommt ganz hinten. Wer den ganzen Tag nur Assembler macht und keine Lust hat etwas neues zu lernen, für den ist alles andere schwer. Wenn aus dem Bastelprojekt ein konkreter Nutzen heraus kommen soll, tut man gut daran, sich an professionellen Prinzipien zu orientieren. Also Abstraktion, Wiederverwendbarkeit, Wartbarkeit, Dokumentation, usw. Assembler-Spaghetti-Code kann man dann schnell wieder vergessen. Joker schrieb: > Aber die AVRs reicht wirklich (mit ein bisschen > Peripherie) für alles aus, wenn man sie ordentlich in Assembler > programmiert! Oder fast nichts, je nachdem von welchen Projekten man redet. Man kann sicherlich mehr Projekte finden, die nicht auf einem AVR laufen als welche, die es tun. Selbst für Kleinstprojekte kann der AVR zu knapp werden. Eine digitale Frequenzweiche für Audioanwendungen dürfte schon nicht mehr gehen. Und das ist wohl eine der einfachsten Aufgaben, die man sich vorstellen kann. Im Endeffekt keine 100 Zeilen Code, selbst in Assembler. Trotzdem ist der dafür zu schwach. Es wäre also Quatsch zu behaupten, dass man erst jahrelang programmieren müsste, bis der ARM voll ist.
Antimedial schrieb: > und keine Lust hat etwas neues zu lernen Ja, man kann seine Zeit dafür verwenden, permanent neues zu lernen. Denn alles Neue ist in diesen Zeiten schnell wieder alt. Oder man investiert die Zeit allein in seine Projekte. Realisiert mit bewährten, einfachen Mitteln. Aufgebautes Controller KnowHow und Programm-Code nutzend. Antimedial schrieb: > Selbst für Kleinstprojekte kann der AVR zu knapp werden. Eine digitale > Frequenzweiche für Audioanwendungen ... ist sicher keine typische AVR Steuerungsanwendung, schon angesichts der zu bewältigenden Datenmassen. Man kann solche für 8Bit/AVR Technik exotisch bis unsinnigen Einsatzfälle aber natürlich stoisch weiter als Argument gegen ihren Einsatz vorbringen ;-) Antimedial schrieb: > Wenn man "einfach" für Bastler definieren will, dann die Lösung mit dem > geringsten Einarbeitungsaufwand von 0. Da ist Arduino, Raspberry Pi Auf Arduino läuft in der Regel welcher Controller- und langt auch für die vielen Arduino Anwendungen? Und wenn man Bastler allein auf Leute reduziert, denen es primär nur ums "Basteln" (ggf. mit einer zentralen Plattform) geht > Beim Hobby geht es um den Weg nicht um das Ziel. ... dann könnte man ja verstehen, Bastelplattformen wie Raspberry Pi noch vor die Verwendung einzelner Chips in selbstgebauter Hardware zu positionieren. Wer aber platzsparend Funktionalität dezentral benötigt, wird sich an dieser Stelle nicht mit fertigen Raspi-oder anderen sperrigen (Entwickler-)Boards aufhalten. Wobei auch die Definition 'Einfach' bei einem komplexen Linuxsystem wie dem Raspi schon sehr gewagt ist... Man sollte eben jenes Brett vorm Kopf nehmen, daß der Hobbybastler nur den Bastel-"Weg" zu beschreiten hätte und nur der Profi befähigt sei, ein seriöses "Ziel" zu realisieren. Dazu müsste man sich allerdings auf Augenhöhe zum Bastler begeben und seine Überheblichkeit zurückfahren- leider ist dazu nicht jeder Fachmann in der Lage ;-(
Moin, will mal auch mal meinen Senf dazugeben. Die Aussage, dass die Anwendungsbreite der AVRs ziemlich groß ist, ist natürlich vollkommen richtig. Ich war immer ein Fan der 8-Bit-AVR-Architektur, einfach weil es halt richtiges RISC ist — pro Befehl mal höchstens 1 oder 2 Taktzyklen, viele Register und wenige Befehle auf Load-/Store-Basis. Da beschäftigt man sich auch gerne mal mit dem AVRSimulator und lernt nebenbei noch eine ganze Menge über Rechnerarchitektur (selbst, wenn einem das erst später klar wird). Und man sieht auch immer wieder klasse Tricks, die mit der Architektur möglich so sind (z.B. B. Kainkas AM-Modulator durch Ausnutzen des Tristates am Portausgang, schöne Idee). Auch die Uzebox zeigt dramatisch, was aus so 'ner Platform herauszuholen ist. Allerdings haben die ganzen 8-Bitter einen Pferdefuss, und der ist halt durch die Prozessorarchitektur bedingt: die Arithmetik. Für einfache Fixkomma-Multiplikationen in 1.7 Form mag's beim AVR ja noch reichen. Muss man aber wirklich mal int32 multiplizieren oder gar dividieren, dann kann man sich's ja überlegen, wieviele 8-Bit-Operationen notwendig sind… und das macht ab einem bestimmten Punkt sicher keinen Spaß mehr. Meist kann man sich ja mit 8-Bit-Approximationen begnügen oder clevere LUTs bauen, aber manchmal kommt man halt um höhere Präzision nicht herum. Erfordert die Appliance dann auch noch gewisse Ansprüche an die Timings, helfen auch die XMegas nur begrenzt. Ob man für alles gleich 'nen 16-Bit-DSP nehmen muss, weiß ich nicht. Als Hobbyist fällt das meist flach, einfach weil die DSP-Umgebungen oft etwas gewohnungsbedürftig sind. Kann da aber ehrlich gesagt auch nur begrenzt Auskunft geben — mal mit 'nem BlackFin und Linux was zu bauen, hätte ich schon Lust, hat sich aber bisher für mich nicht ergeben. Stattdessen kann ich die ARMs auch nur empfehlen. Alles schön RISC und Load/Store, aber mit Assembler muss sich keiner mehr wirklich abmühen, da der Befehlssatz nahezu optimal für die Compiler ausgelegt ist. Oft bringen die ARM-Prozessoren auch DSP-Erweiterungen mit, für arm-hardfloat (FPU) reichts aber oft nicht (siehe Rasp). Für arithmetisch aufwendigere Sachen bzw. mehr Präzision beim Rechnen skaliert ein ARM weitaus besser als ein klassischer 8-Bit-AVR.
Marc O.S. schrieb: > Und trotz Z-Dioden und Kondensatoren und sonstigen elektrischen Schutz, > sind 8-Bit MCUs einfach nur unzuverlässig, wenn du in der > Prototypenphase mal öfters ein- und ausstecken musst - nichts, was du > nicht wahrscheinlich schon weisst, wenn du solche Fragen stellst. Mit > 32-Bit MCUs hast du das Problem ganz einfach nicht. Soso. Du hast also irgendwann mal im Leben EIN vergurktes Projekt gesehen (bei dem übrigens der Architekt und nicht der Baustein versagt hat) und das verallgemeinerst Du jetzt mal locker flockig auf alle 8-Bit CPUs (denn mit Deinen 50 Jahren Berufserfahrung kennst sie ja mittlerweile alle), und die Tatsache daß das eigentliche (von Dir beschriebene) Problem überhaupt gar nichts (aber mal so was von gar nichts) mit 8 Bit oder wieviel bit auch immer zu tun hat lässt Du dabei unauffällig unter den Tisch fallen.
:
Bearbeitet durch User
> Und trotz Z-Dioden und Kondensatoren und sonstigen elektrischen Schutz, > sind 8-Bit MCUs einfach nur unzuverlässig, wenn du in der > Prototypenphase mal öfters ein- und ausstecken musst - nichts, was du > nicht wahrscheinlich schon weisst, wenn du solche Fragen stellst. Mit > 32-Bit MCUs hast du das Problem ganz einfach nicht. Aeh... ein Studi mit Null Ahnung. Nur weil der 32bitter das bessere Board verlangt... Einsteck Probleme sind EMV Probleme, und die muss man unabhaengig von der Architektur im Griff haben.
Moby schrieb: > Ja, man kann seine Zeit dafür verwenden, permanent neues zu lernen. > Denn alles Neue ist in diesen Zeiten schnell wieder alt. > Oder man investiert die Zeit allein in seine Projekte. > Realisiert mit bewährten, einfachen Mitteln. > Aufgebautes Controller KnowHow und Programm-Code nutzend. Kann man machen, als Bastler, wenn man sich nicht mit der Technik weiter entwickeln will. Wer Interesse an Neuem hat, macht das so nicht. Dummerweise schießt dich dein Argument selbst ab, weil C-Code viel besser wartbar und portabel ist, man also sein Know-How viel effizienter nutzen kann. Moby schrieb: > ... ist sicher keine typische AVR Steuerungsanwendung, schon angesichts > der zu bewältigenden Datenmassen. Man kann solche für 8Bit/AVR Technik > exotisch bis unsinnigen Einsatzfälle aber natürlich stoisch weiter als > Argument gegen ihren Einsatz vorbringen ;-) Ein Audiofilter ist alles andere als exotisch. Man kann natürlich mit Gewalt alle Anwendungen, die nicht auf dem AVR laufen, als exotisch deklarieren, dann ist man fein raus. Dummerweise kann man dann immer noch alle Aufgaben genauso gut oder besser mit einem M0 lösen. Moby schrieb: > Wobei auch die Definition > 'Einfach' bei einem komplexen Linuxsystem wie dem Raspi schon sehr > gewagt ist... Wenn man den Begriff Abstraktion versteht, dann würde man das nicht als gewagt bezeichnen. Das Raspberry Pi ist für den Anwender einfacher als AVR. Allein weil man es in Python entwickeln kann, welches viel einfacher zu lernen ist als C oder gar Assembler. Moby schrieb: > Man sollte eben jenes Brett vorm Kopf nehmen, daß der Hobbybastler nur > den Bastel-"Weg" zu beschreiten hätte und nur der Profi befähigt sei, > ein seriöses "Ziel" zu realisieren. Kann man machen, aber als Bastler hat man immer noch die Freiheit, nicht das sinnvollste Werkzeug zu wählen. Wenn man nach professionellen Maßstäben arbeitet, führt für einfache Steuerungsaufgaben heute kaum noch ein Weg am Cortex M vorbei. db8fs schrieb: > lernt > nebenbei noch eine ganze Menge über Rechnerarchitektur (selbst, wenn > einem das erst später klar wird). Wenn man wirklich was über Rechnerarchitekturen lernen will, nimmt man besser ein FPGA-Softcoresystem und baut sich dafür eigene Kerne. Beim Nios kann man sogar eigene Assemblerbefehle entwickeln. Die Methode wird teilweise auch im Informatikstudium genutzt, um Rechnerarchitekturen praxisnah zu lehren.
Antimedial schrieb: > Dummerweise schießt dich dein Argument selbst ab, weil C-Code viel > besser wartbar und portabel ist, man also sein Know-How viel effizienter > nutzen kann. Oh, oh, damit rufst Du jetzt aber Moby auf den Plan :)
Antimedial schrieb: > Wenn man nach professionellen > Maßstäben arbeitet, führt für einfache Steuerungsaufgaben heute kaum > noch ein Weg am Cortex M vorbei. Eine ernst gemeinte Frage nebenbei: Es gibt ja Cortexe, die Preislich auch recht günstige 8bitter schlagen. Doch wieso entwickeln die Hersteller fleißig an den 8bittern? Die neuen EFM8, 8bit PICs kommen auch immer neue und die sind sicherlich nicht die einzigen (bei denen weiß ich es aber). Doch wieso tun sie das, wenn man für das gleiche Geld doch schon nen M0 bekommt? Hobbyisten interessieren die ja relativ wenig und in der Industrie braucht/will man ja auch immer weniger DIP Gehäuse, weshalb das Argument auch flach fällt. Es geht doch eigentlich um Leistung / Features und Preis. Wenn die sich preislich nichts nehmen und die ARMs ja besser sein sollen, wozu dann neue 8bitter? Ich bin über neue 8bit PICs ganz froh, wobei die das denke ich mal eher weniger beeinflusst.
Michael Skropski schrieb: > Doch wieso entwickeln die > Hersteller fleißig an den 8bittern? Von der EFM8-Webseite: EFM8 extends battery life with ultra-low sleep currents down to 50 nA with Brown out detection, fast wake-up times with less than 2 μs, active currents as low as 150 μA per MHz and a low energy USB module. In manchen Fällen sind 8-bit eben mehr als genug, da sind die anderen 24 Bit einfach Verschwendung. Auch, wenn sie mehr oder weniger gratis sind.
Michael Skropski schrieb: > Eine ernst gemeinte Frage nebenbei: Es gibt ja Cortexe, die Preislich > auch recht günstige 8bitter schlagen. Doch wieso entwickeln die > Hersteller fleißig an den 8bittern? Fleißig würde ich jetzt nicht sagen. Fast jeder Hersteller, der früher eigene 8-Bit-Cores entwickelt hat, hat jetzt auch Cortex M0. Dazu gehört ST, Infineon, Spansion (früher Fujitsu) aber auch Atmel. Und bei Microchip ist es noch so, dass sie nichts vergleichbares zum Cortex M0 in 32 Bit haben. Ich bin mal gespannt, was da in den nächsten Jahren passiert. Reagieren müssen sie. Entweder entwickeln sie schon etwas passendes im Hintergrund oder sie werden durch eine Akquise reagieren. Das hätte den Vorteil, dass man nicht zugeben muss, den Trend verschlafen zu haben. Man kauft dann einfach die Firma "aus wirtschaftlichen Gründen" und plötzlich hat man ganz zufällig die Cortex M0 im Programm. Dummerweise bleiben nicht viele kleine Cortex-Hersteller übrig. Ein bisschen Produktpflege muss man noch machen. Schließlich bauen einige ihrer Kunden Produkte 20 Jahre lang ohne große Veränderung, und da muss man vielleicht mal auf einen neuen Prozess umstellen (Die-Shrink, der Baustein wird auch günstiger). Es gibt auch im professionellen Umfeld Leute, die noch nicht umgestiegen sind. Man kann logischerweise nicht während eines laufenden Projekts umsteigen. Viele Industrieprojekte haben Laufzeiten von über drei Jahren, und vor drei Jahren war der M0 noch nicht so verbreitet. Und bei der Pflege einer laufenden Serie (wie gesagt teilweise >20 Jahre) steigt man auch nicht ohne Not um. Ein großflächiger Wandel dauert sicher noch viele Jahre. Und so lange gibt es hin und wieder Bedarf an neuen Chips. Markus H. schrieb: > EFM8 extends battery life with ultra-low sleep currents down to > 50 nA with Brown out detection, fast wake-up times with less than > 2 μs, active currents as low as 150 μA per MHz and a low energy USB > module. Das ist aber überhaupt nicht beeindruckend, wenn man sich im Vergleich die Zero Gecko Serien aus dem gleichen Haus anschaut. Und durch die höhere Leistung kann man langsamer takten oder schneller in den Ruhezustand zurück gehen. Vielleicht findet man einen Modus, indem der EFM8 noch etwas weniger Strom braucht. Außerdem muss da noch der Rest der Schaltung mit spielen. Da muss man sich schon einen besonderen Fall konstruieren. Den gibt es sicherlich, die neuen Chips wurden bestimmt auf die Anforderung einer speziellen Kundschaft entwickelt.
Marc O.S. schrieb: > Oliver S. schrieb: >> Na ja, das ist so pauschal Unsinn. > > War ja ne ziemliche Verallgemeinerung, aber spürbar stabiler und > robuster sind sie nach meiner Erfahrung eigtl. schon. Die 32-bitter? Nö, warum sollten sie robuster sein? Im Gegenteil, der 8-bitter mit seinen grösseren Chipstrukturen ist da robuster und kann z.B. auch mehr Wärme abführen, während sich beim eng gebauten 32-bitter Hotspots bilden können. Vom Übersprechen im ADC mal abgesehen - wer mit den STM32 experimentiert, erlebt da viel Spass. Nicht umsonst setzen die Satelliten Konstrukteure gerne mal simplere CPUs ein, damit beim Strahlenbombardement nicht so viel Unsinn passiert. Markus H. schrieb: > In manchen Fällen sind 8-bit eben mehr als genug, da sind die anderen 24 > Bit einfach Verschwendung. Auch, wenn sie mehr oder weniger gratis sind. Ja, natürlich. Es war auch klar, das der TE mit seiner Frage wieder einen unnötigen Flamewar auslöst, obwohl das nicht seine Absicht war. Man setzt eben den MC ein, der die Aufgabe erfüllt, und ein wenig Luft nach oben hat, zumindest in der Entwicklungsphase. Wenn alles spielt, kann man für die Serie evtl. an Kosten sparen und was etwas kleineres nehmen.
:
Bearbeitet durch User
Matthias Sch. schrieb: > Nicht umsonst setzen die Satelliten Konstrukteure gerne mal simplere > CPUs ein, damit beim Strahlenbombardement nicht so viel Unsinn passiert. Das halte ich für ein Gerücht. In der Raumfahrt werden schon große Prozessoren eingesetzt (PowerPC, Sparc), nur eben großen Strukturbreiten. Die sind dann logischerweise langsamer, brauchen viel Strom und sind sehr, sehr viel teurer. Aber sie sind nicht einfach. Siehe: http://en.wikipedia.org/wiki/RAD750 http://de.wikipedia.org/wiki/LEON In neueren Entwicklungen geht man auf fehlertolerante Systeme, um dann doch auf kleinere Strukturbreiten (teilweise FPGA) zu gehen. Das ist einfach billiger und effizienter.
Andreas Messer schrieb: > Es ist im übrigen völliger Unsinn, das C++ bzw OOP Leistung > verschwendet. Vielmehr erlaubt es eine vielfach bessere > Wiederverwertbarkeit von Code. Man denke nur an Templates & Co. Man muss > halt nur wissen was man tut. Z.b. transparent auf eeprom/flash > zugreifen: > #if defined(USE_FLASH) > static FlashVariable<uint8_t> myvar PROGMEM = {10}; > #elif defined(USE_EEPROM) > static EEVariable<uint8_t> myvar EEMEM = {10}; > #elif defined(USE_RAM) > static uint8_t myvar = 10; > #endif > > void main() > { > uint8_t x = myvar; /* I don't care where myvar is stored */ > myvar = 5; /* store in eeprom or flash or ram*/ > } Das ist in meinen Augen ein absolut blödes Beispiel. Keine Sau weiß mehr in 5 Jahren in der 20. Datei eines 128k Projektes dass sich hinter der Zeile: myvar=5 etwas anderes verbirgt als eine einfache Variablenzuweisung. Sowas wie: write_eemem(&myvar, 5) macht für jeden sofort erkennbar was hier abgeht. Klar kann man auch Kommentare schreiben. Dann brauch im mir aber auch nicht deinen oben gezeigten Aufwand zu machen, wenn ich am Ende genauso viel tippen muss.
Antimedial schrieb: > Moby schrieb: > Moby schrieb: > Moby schrieb: > Moby schrieb: Ich nehme das mal als Entschuldigung für den Trollvorwurf an, sonst würdest Du nicht immerfort antworten... > Dummerweise schießt dich dein Argument selbst ab, weil C-Code viel > besser wartbar und portabel ist, man also sein Know-How viel effizienter > nutzen kann. Mal ganz davon abgesehen, daß hardwarenahes C nun auch nicht gerade die Leuchte der Portabilität darstellt - dummerweise stehe ich gar nicht erst vor der Notwendigkeit, die Architektur wechseln zu müssen: AVR (erst recht mitsamt effizentem Asm) hat soviel Potential, daß es selbst dem TO hier ("seit einigen Jahren jetzt mit 8bit AVRs") schon unheimlich vorkommt und er ohne jede konkrete Anforderung unsicher ins Blaue hinein fragt: Ist das Ding noch zeitgemäß? Vielleicht sollte man bei der Gelegenheit noch mal in Erinnerung rufen, daß so ein AVR-Mega, im Prinzip auch schon jeder Tiny, einen Z80- immerhin früher fester Bestandteil "professioneller" Technik, in Leistung und Funktion locker in die Tasche steckt. Also Antimedial- nicht blind und beständig allein ins "Neue", Schnellere und in die (ungenutzten) Features verlieben, sondern schön die konkreten Anforderungen vor Auge haben! Stichwort "Professionell": Das sollte man nicht unbedingt mit "Industriell"er Anforderung verwechseln. Eine professionelle Lösung ist eine, die eine Problemstellung dauerhaft, nebenwirkungs- und fehlerfrei löst. Und die Umsetzung ist umso professioneller, je einfacher diese gelingt- was mit Kanonen auf Spatzen schießen ausschließt. Das kriegt dann auch der engagierte Bastler hin! db8fs schrieb: > mehr Präzision beim Rechnen bietet 32 Bit allemal- nur ist das bei einem Großteil der 8-Bit Steuerungsanwendungen gar nicht gefragt. Wenn ich hier allein mal für das weite AVR-Einsatzfeld der Home-Automation sprechen darf: So sich die Umformung von Sensor-Messwerten nicht gerade auf 2er Potenz frisiert/shiftend berechnen lässt spielt selbst eine größere Berechnung mit allseits erhältlichem, optimierten Asm Code gar keine Rolle, wenn der dezentrale Sensorknoten sowieso nur 1,2,5,10 Messwerte pro Sekunde abliefert. Stichwort "dezentral": Das kommt im alten Antimedial-en Mainfraime Denken mit Zentralsteuerung und Protzprozessor natürlich gar nicht vor. Dabei sind es diese Netzwerke von Sensorknoten, die modern sind! Und wenn man den Auguren des IoT glauben darf findet die logische Auswertung/ Verarbeitung ja zukünftig sowieso auf Servern im Netz statt- und nicht auf fettem lokalen ARM-Controller. Aber unter uns: Ein netter XMega tuts vorerst genauso ;-)
Kommt mir das nur so vor, oder ist Mobys einziges Argument, dass ihm die Rechenleistung eines AVRs genügt.
hansjörg schrieb: > dass ihm > die Rechenleistung eines AVRs genügt. Nein Hansjörg. Sie langt -generell- für mehr als Du glaubst oder zuzugeben bereit bist ;-)
Markus H. schrieb: > In manchen Fällen sind 8-bit eben mehr als genug, da sind die anderen 24 > Bit einfach Verschwendung. Auch, wenn sie mehr oder weniger gratis sind. Bin ganz deiner Meinung. Doch so wie ich das mitbekommen habe, spielt in der Industrie neben Geld und Geld, auch noch Geld und Leistung eine Rolle. Und wenn beides gleich oder eher in Richtung 32bit geht, wieso dann 8bit neu entwickeln? Auch bei Microchip sind die neuen Features wie NCO, CLC, ZeroCross Detection erst bei den PIC16, dann irgendwann vielleicht bei PIC18 und dann nochmal später, wenn überhaupt bei den 16bittern. Wollen die damit ihre 8bitter pushen? Oder wird in dem Markt, wo diese Funktionen benutzt werden, eher 8bitter eingesetzt? Antimedial schrieb: > Und bei Microchip ist es noch so, dass sie nichts vergleichbares zum > Cortex M0 in 32 Bit haben. Das stimmt. Die PIC32 liegen wohl eher so bei M3 oder M4. Davor sind die 16bitter. Antimedial schrieb: > Das ist aber überhaupt nicht beeindruckend, wenn man sich im Vergleich > die Zero Gecko Serien aus dem gleichen Haus anschaut. Das hab ich mir auch gedacht. Ich kann ja auch verstehen, dass manche bei ihren 8bittern bleiben, aber wieso dann neue? Wenn schon eine Umstellung ist es doch schon fast egal, ob neuer 8bitter oder neuer M0.
hansjörg schrieb: > Kommt mir das nur so vor, oder ist Mobys einziges Argument, dass ihm > die Rechenleistung eines AVRs genügt. Mobys einziges Argument ist simple: Er kennt nur seinen AVR8-ASM Hammer, deswegen sieht jedes Problem aus wie ein AVR8-ASM Nagel. Michael Skropski schrieb: >> In manchen Fällen sind 8-bit eben mehr als genug, da sind die anderen 24 >> Bit einfach Verschwendung. Auch, wenn sie mehr oder weniger gratis sind. In immer mehr Cortex-M0 Fällen sind die 24 zusätlichen bits nicht nur gratis, sondern 32-Bit billiger als Bit. Auch für Ultra-Low-Power Anwender Geckos (falls die größten Kosten in der Stromversorgung anfallen) Für den Hobbiesten auch wichtig: Debugger für STM32 und LPCs (LPCXpresso z.b) werden einem für wenige Euro nachgeworfen, bei Atmel investiert man mindestens 50€ in einen AVR Dragon. Diejenigen die jetzt behaupten noch nie einen Debugger gebraucht zu haben und nie einen brauchen werdne, haben imho noch nie den Komfort einer Käferjagd on Chip erlebt - oder produzieren jeder Zeit perfekten Code ;) Moby schrieb: > Eine professionelle Lösung ist > eine, die eine Problemstellung dauerhaft, nebenwirkungs- und fehlerfrei > löst. Zu dauerhaftigkeit gehört auch Wartbarkeit, auch nach x Jahren und auch durch andere als den ursprünglichen Entwickler. Moby schrieb: > was mit Kanonen auf Spatzen schießen ausschließt. Manchmal werden die Spatzen plötzlich Adler, wenn man später noch Erweitern und Ausbauen will. Und dann bereut man das Projekt in den kleinsten uC mit ASM gequetscht zu haben.
Scelumbro schrieb: > Für den Hobbiesten auch wichtig: Debugger für STM32 und LPCs (LPCXpresso > z.b) werden einem für wenige Euro nachgeworfen SimulAVR ist Open Source, gratis und prima für's Debugging geeignet. > Diejenigen die jetzt behaupten noch nie einen Debugger gebraucht zu > haben und nie einen brauchen werdne, haben imho noch nie den Komfort > einer Käferjagd on Chip erlebt Diejenigen, die einen Debugger für das Mass aller Dinge halten, hatten es offensichtlich noch nie mit zeitkritischen Anwendungen zu tun. Da ist schon der Break in den Debugger ein No-Go. Bei SimulAVR hält man bei einem Break übrigens nicht nur den Programmfluss, sondern auch die Uhr an. Dann klappt das wieder.
Markus H. schrieb: > Scelumbro schrieb: >> Für den Hobbiesten auch wichtig: Debugger für STM32 und LPCs (LPCXpresso >> z.b) werden einem für wenige Euro nachgeworfen > > SimulAVR ist Open Source, gratis und prima für's Debugging geeignet. Aber was ist wenn ich Peripherie am µC habe, z.B. eine SD Karte am SPI? Der Bug tritt aber erst nach der SD Karten Initialisierung und im Zusammenspiel mit den Daten darauf auf. Was mach ich dann?
Markus H. schrieb: > SimulAVR ist Open Source, gratis und prima für's Debugging geeignet. Das hilft nicht wirklich. Meist ist es so daß man ihn in der realen Schaltung laufen lassen will (muss) bis eine ganz bestimmte Situation eintritt, dann will man eines von folgenden beiden tun: (1) Den Inhalt einer ganz bestimmten Variablen ausgeben lassen (mangels Debugger z.B. an nem freien Pin per behelfsmäßigem Software-UART rausklopfen) oder (2) Den Prozessor anhalten per Breakpoint und mit dem Debugger den Zustand untersuchen. Vorgehensweise 1 sollte man zumindest mal geübt und praktiziert haben, das sollte zum Repertoire gehören für alle Fälle in denen man keinen Debugger anschließen kann. Meist reicht das allein schon aus für die meisten Probleme die auftreten könnten oftmals ist es in der Praxis auch die einzige Möglichkeit. Natürlich nimmt man stets (2) statt (1) wenn man die Möglichkeit dazu hat, das versteht sich ja von selbst, es ist einfach effektiver und komfortabler. Aber wie mir eine Simulation des Prozessors beim Debuggen helfen sollte bei einem Bug der nur in der realen Schaltung bei der Interaktion mit angeschlossener Peripherie auftritt, dazu fällt mir jetzt echt kein Einsatzzweck ein. Evtl ist ein solcher Simulator hilfreich als Anschauungsobjekt zu Ausbildungs- und Lehrzwecken oder evtl auch zur Dürchführung automatisierter Unit-Tests für algorithmischen Code oder zur Verifikation des Compilers selbst. Aber fürs Debuggen in der täglichen Praxis glaub ich eher weniger.
TriHexagon schrieb: > Aber was ist wenn ich Peripherie am µC habe, z.B. eine SD Karte am SPI? Zum Einen kann man auch dem SimulAVR Peripherie verpassen und zum Anderen gibt es immer noch das printf()-debugging. Und drittens, ja, es gibt auch Fälle, in denen ein Hardware-Debugger sinnvoll ist. Ist ja nicht alles zeitkritisch.
Markus H. schrieb: > TriHexagon schrieb: >> Aber was ist wenn ich Peripherie am µC habe, z.B. eine SD Karte am SPI? > > Zum Einen kann man auch dem SimulAVR Peripherie verpassen und zum > Anderen gibt es immer noch das printf()-debugging. Und drittens, ja, es > gibt auch Fälle, in denen ein Hardware-Debugger sinnvoll ist. Ist ja > nicht alles zeitkritisch. Ah, dass man dem Simulator Peripherie hinzufügen kann, wusste ich nicht. Das printf()-Debugging hab ich immer benutzt, wirklich komfortabel war das aber nie :(.
Bernd K. schrieb: > dann will man eines von folgenden beiden tun: > > (1) Den Inhalt einer ganz bestimmten Variablen ausgeben lassen (mangels > Debugger z.B. an nem freien Pin per behelfsmäßigem Software-UART > rausklopfen) > > oder > > (2) Den Prozessor anhalten per Breakpoint und mit dem Debugger den > Zustand untersuchen. Beides geht mit SimulAVR ganz problemlos. Sogar besser, denn der Software-UART funktioniert im Simulator auch dann, wenn man den Simulator mitten während des verschickens eines Bytes anhält. Bei echter Hardware ist dieses Byte futsch, denn Pausen erlaubt das serielle Protokoll nicht. Wie im Beitrag drüber geschrieben, Grenzen hat der Simulator vor Allem da, wo es keine simulierte Peripherie gibt.
Scelumbro schrieb: > deswegen sieht jedes Problem aus wie ein AVR8-ASM Nagel. Na bestimmt nicht jedes, aber immerhin sind es doch sehr sehr viele. Tipp: Die Anforderungen der Anwendung entscheiden lassen. > Zu dauerhaftigkeit gehört auch Wartbarkeit, auch nach x Jahren und auch > durch andere als den ursprünglichen Entwickler. Lässt sich in Asm doch genauso sicherstellen. Stell Dir vor, da sind auch Kommentare, ist auch zusätzliche Doku möglich! > Und dann bereut man das Projekt in den > kleinsten uC mit ASM gequetscht zu haben. Nö. Vorausschauend planen ist mit Asm genauso möglich. Nur sind die Reserven größer. Und da man alles selbst in der Hand hat gibt es diesbezüglich auch keine bösen Überraschungen mit zukünfigen Compilern, Library- und anderen Versionen zugelieferten Codes.
Moby schrieb: > Mal ganz davon abgesehen, daß hardwarenahes C nun auch nicht gerade die > Leuchte der Portabilität darstellt - dummerweise stehe ich gar nicht > erst vor der Notwendigkeit, die Architektur wechseln zu müssen: AVR > (erst recht mitsamt effizentem Asm) hat soviel Potential Wie gesagt, ein AVR reicht nicht einmal für ein Audiofilter. Hardwarenahes C ist Unsinn. Ich arbeite immer mit einer HAL. Meine Programme laufen auf AVR, STM32 und oft sogar PC. Falls ich einen neuen Prozessor brauche, setze ich mich einen Tag hin, schreibe eine neue HAL und kann alle meine Projekte auf einen Schlag portieren. Ich suche mir nicht meine Projekte nach der Plattform heraus, die ich gerade verstehe, sondern umgekehrt. Ich mache ein Projekt, das mir Spaß macht und suche die dafür optimale Plattform heraus. Einen AVR habe ich dafür in den letzten 3 Jahren nicht mehr gebraucht. Moby schrieb: > Ich nehme das mal als Entschuldigung für den Trollvorwurf an, sonst > würdest Du nicht immerfort antworten... Auch ein ganz klarer Trollversuch muss man nicht einfach so stehen lassen. Schließlich lesen das auch unbedarfte Leute. Moby schrieb: > Stichwort "Professionell": Das sollte man nicht unbedingt mit > "Industriell"er Anforderung verwechseln. Eine professionelle Lösung ist > eine, die eine Problemstellung dauerhaft, nebenwirkungs- und fehlerfrei > löst. Profi ist der, der Geld damit verdient. Moby schrieb: > Und die Umsetzung ist umso professioneller, je einfacher diese > gelingt- was mit Kanonen auf Spatzen schießen ausschließt. Nein, professionell heißt heute in erster Linie wartbar und portabel. Anders kann man heute kein Geld mehr verdienen, weil man die Zeit in die Pflege des Codes steckt. Und das schließt Assembler in aller Regel aus. Moby schrieb: > Nö. Vorausschauend planen ist mit Asm genauso möglich. > Nur sind die Reserven größer. Mal davon abgesehen, dass das ein uraltes Vorurteil ist, welches einfach nicht stimmt. Reserven kann man sich anders beschaffen, indem man einen Prozessor mit viel mehr Speicher und Rechenleistung nimmt. Der ist auch noch günstiger.
Antimedial schrieb: > Reserven kann man sich anders beschaffen, indem man einen > Prozessor mit viel mehr Speicher und Rechenleistung nimmt. Genau das ist doch der sich aufschaukelnde Zyklus. Jahr für Jahr mehr Rechenleistung und Speicher- selbst für einfache Anwendungen. Weil die Controller Jahr für Jahr mit mehr Layern, Abstraktionen und OOP-Strukturen zugepflastert werden. Natürlich im Zeichen vermeintlichen Fortschritts. Das vorläufige Endstadium dieser Ressourcen-vernichtenden Entwicklung ist bei PC-Software zu besichtigen.
Moby schrieb: > Weil die Controller Jahr für Jahr mit mehr Layern, > Abstraktionen und OOP-Strukturen zugepflastert werden. Das typische Vorurteil von Leuten, die noch nie damit gearbeitet haben. Meine Programme sind mit neueren Prozessoren einfacher und performanter, weil sie unter anderem DMA nutzen und damit größtenteils mit keinem oder maximal einem Interrupt auskommen. Da fallen so viele zeitliche Abhängigkeiten weg, die ein Programm komplex machen. Moby schrieb: > Natürlich im Zeichen vermeintlichen Fortschritts. Der Fortschritt heißt Wartbarkeit. Nur so kann man überhaupt komplexe Aufgaben beherrschen. Bei kleineren Aufgaben, wie du sie machst, ist das nicht zwingend nötig, macht aber das Leben einfacher. Manche wollen es aber schwer haben. Und im Hobbybereich ist das auch völlig in Ordnung. Moby schrieb: > Das vorläufige Endstadium dieser Ressourcen-vernichtenden Entwicklung > ist bei PC-Software zu besichtigen. Der Peak wurde vor einigen Jahren mit Windows 7 erreicht. Seitdem sinken die Anforderungen eher wieder, auch wegen dem Tablet- und Smartphone-Trend. Was sich in den letzten Jahren im Bereich Effizienz bei Scriptsprachen getan hat, ist eine absolute Revolution. Ein für dich voller Abstraktion überladenes Node.js steckt jeden in C programmierten Apache locker in die Tasche.
Da hier auch unbedarfte Leute mitlesen sollte Trollerei natürlich widersprochen werden. Sonst bekommt noch jemand den Eindruck, Problemlösungen mit ARM seien das Normalste der Welt ;-) Antimedial schrieb: > Meine Programme sind mit neueren Prozessoren einfacher und performanter, > weil sie unter anderem DMA nutzen und damit größtenteils mit keinem oder > maximal einem Interrupt auskommen. Da fallen so viele zeitliche > Abhängigkeiten weg, die ein Programm komplex machen. Und Du meinst, das ginge mit einem Xmega nicht so? Sehr innovativ vor allem das neue Event-System. Antimedial schrieb: > Manche wollen es > aber schwer haben. Irrtum. Möglichst einfach. Antimedial schrieb: > Der Peak wurde vor einigen Jahren mit Windows 7 erreicht. Seitdem sinken > die Anforderungen eher wieder, auch wegen dem Tablet- und > Smartphone-Trend. Was den PC betrifft: Wer's glaubt. Und bei Tabletts und Smartphones eher, weil damit ein gewisser Neustart verbunden war. Daß sich hier nicht der gleiche Trend wie bei PCs einstellt- eine sehr schwache Hoffnung. Antimedial schrieb: > Wie gesagt, ein AVR reicht nicht einmal für ein Audiofilter. Ich sagte ja, stoisch...
Schön, dass ihr beiden euch endlich gefunden habt, ein Traumpaar! Heiratet ihr jetzt? ;-)
Wie würde so eine sinnvolle Abstrahierung für IO-Pins eigentlich aussehen?
Markus H. schrieb: > Grenzen hat der Simulator vor Allem da, wo es keine simulierte > Peripherie gibt. Oder da, wo man die Reaktion externer Geräte nicht simulieren kann. hansjörg schrieb: > Wie würde so eine sinnvolle Abstrahierung für IO-Pins eigentlich > aussehen? Das hängt davon ab, auf welcher Ebene du abstrahieren willst. Ein Extrembeispiel wäre die Arduino-Umgebung, bei der du mit einem DigitalWrite(5, LOW) halt immer den Pin veränderst, an deinem Board die Nummer 5 hat – egal, was für einen Prozessor du drunter hast und welcher MCU-Pin sich dahinter verbirgt.
hansjörg schrieb: > Wie würde so eine sinnvolle Abstrahierung für IO-Pins eigentlich > aussehen? Vielleicht so:
1 | const int LedPin = 13; |
Nachtrag:
> Ein Extrembeispiel wäre die Arduino-Umgebung,
zu spät gesehen ..
Moby schrieb: > Sonst bekommt noch jemand den Eindruck, > Problemlösungen mit ARM seien das Normalste der Welt ;-) Ist es auch. Zumindest bei Profis. Assembler ist dagegen alles andere als normal Moby schrieb: > Und Du meinst, das ginge mit einem Xmega nicht so? > Sehr innovativ vor allem das neue Event-System. Ja, natürlich, braucht man aber nicht. Ein Event-System braucht aber eine DMA. Moby schrieb: > Irrtum. Möglichst einfach. Dein Hang zu Assembler und deine Weigerung gegenüber Abstrahierung widersprechen dem. Moby schrieb: > Was den PC betrifft: Wer's glaubt. > Und bei Tabletts und Smartphones eher, weil damit ein gewisser Neustart > verbunden war. Daß sich hier nicht der gleiche Trend wie bei PCs > einstellt- eine sehr schwache Hoffnung. Wer keine Ahnung hat... Beispiele habe ich genug genannt. Kann man ignorieren. Recht hat man dann aber nicht. hansjörg schrieb: > Wie würde so eine sinnvolle Abstrahierung für IO-Pins eigentlich > aussehen? led1 = gpio(GPIOB, 5); gpio_set(&led1);
Antimedial schrieb: > Ein Event-System braucht aber > eine DMA. Das eine hat beim Xmega mit dem anderen rein gar nichts zu tun. Antimedial schrieb: > Wer keine Ahnung hat... sollte sich erst mal informieren ;-)
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.