Moin, gerne wollte ich euch um euren Rat fragen. Ich habe aktuell ein Problem, wofür ich nicht so wirklich eine Lösung, bez. ein Ansatz habe wie ich das Problem lösen könnte. Es geht darum, dass ich mir ein Prozessor von Microchip AVR AVR128DB28 gekauft habe. Das habe ich aus dem Grund getan, da dieser eine Taktgeschwindigkeit von 24 MHz und somit eine Höhere Taktgeschwindigkeit wie die anderen AVR Prozessoren besitzt. Den Prozessor habe ich soweit mit der Arduino IDE zum „laufen“ gebracht. Also ich aber den AVR128DB28 mit meinem Programm beschreiben wollte, musste ich leider feststellen dass das nicht klappte, da es da Probleme mit den Bibliothek gab. In meinem Programm verwende ich ein OLED Display mit der Bibliothek SSD1309. Ausserdem noch die standart NeopixelLEDs mit der Bibliothek FastLED. Beides lässt sich nicht auf dem Prozessor falschen. Ich weiß nicht, ob ich jetzt davon richtig ausgehe, dass es damit zu tun hat, da in den Bibliotheken der Prozessor AVR128DB28 nicht „programmiert“ ist? Jedenfalls hab ich da mal versucht zu überprüfen, ob das der Fall sein könnte. Übrigens hatte ich das selbe Problem mit der FastLED-Bibliothek bei dem Arduino DUE. Die funktioniert bei dem Board auch nicht. An der Stelle gehe ich davon aus, dass es daran liegt, das sich auf dem DUE ein ARM Prozessor befindet. Jetzt stellt sich mir die Frage, wie ich das hinbekommen kann die Bibliothek mit dem Prozessor AVR128DB28 zu nutzen? Über eure Anteilnahme möchte ich mich an der Stelle bedanken. Besten Grüße Sebastian
Sebastian H. schrieb: > wie ich das hinbekommen kann die Bibliothek mit dem Prozessor AVR128DB28 > zu nutzen programmieren lernen, Datenblätter lesen, Bibliothek forken, fixen, fertig
Daniel F. schrieb: > programmieren lernen, Datenblätter lesen, Bibliothek forken, fixen, > fertig Haha. Daß Arduino es dem Anwender vereinfachen soll ist Dir bekannt? Klar, bei solchen Problemen zeigt sich die andere Arduino-Seite. Hat alles seinen Preis. Hier einen Nachteil gegenüber konventioneller Programmierung: Alles nicht immer so aktuell wie man es sich wünscht.
Hallo, was hast du denn wie mit der IDE gemacht zur Anpassung an den AVRxDB? Hast du das DxCore Package von Spencekonde hinzugefügt? Links zu fremden Libs sind auch sinnvoll. Es gibt Hunderte mit gleichen Namen.
Angehängte Dateien:
-
AVR_DB.png
100 KB
Sebastian H. schrieb: > Prozessor AVR128DB28 AVR128DB28 ist kein Prozessor, sondern ein Controller.
Hardware nahe Zugriffe, die ein bestimmtes Timing erfordern, muß man immer auf das konkrete Target anpassen. Auch kann man nicht so einfach einen höheren CPU-Takt verwenden. Es kann sein, daß der Takt in der Lib in einem kleinen Bereich variabel ist, er kann aber auch fix sein (z.B. 16MHz). Es gibt also viele Baustellen, wenn man das Target wechseln will. Ohne Verständnis des Quellcodes der Libs wird das nichts. Will man nicht programmieren lernen, muß man genau die Targets mit genau der Taktfrequenz nehmen, für die die Libs angepaßt sind. Welche das sind, sollte in der Doku zu den Libs stehen.
Einige Bibliotheken enthalten Code, der ganz spezifisch für einen einzelnen oder eine Reihe von Mikrocontrollern geschrieben wurde. Diese funktionieren dann auch anderen Mikrocontrollern nicht. Normalerweise liste die Autoren alle Hardwarekomponenten auf, für die ihr Code vorgesehen ist. Im Falle eine Inkompatibilität musst du halt andere passende Bibliotheken finden oder dir eine eigene selbst programmieren oder eine vorhandene Bibliothek anpassen. Daniels Antwort passt: Daniel F. schrieb: > programmieren lernen, Datenblätter lesen, Bibliothek forken, fixen, > fertig
Veit D. schrieb: > Links zu fremden > Libs sind auch sinnvoll. Es gibt Hunderte mit gleichen Namen. Wohl war! Man muß schon den Link darauf posten, was man konkret benutzt. Sonst versteht der eine Äpfel, wenn der andere Birnen meint. Niemand kann in Deinen Kopf schauen.
Peter D. schrieb: > Hardware nahe Zugriffe, die ein bestimmtes Timing erfordern, muß man > immer auf das konkrete Target anpassen. Auch kann man nicht so einfach > einen höheren CPU-Takt verwenden. In der Regel ist das so; das im Eingangsbeitrag genannte Display (besser: dessen Controller) steuert der geneigte Arduinobastler aber meist mit I²C an, und da sollte man mit der Funktionalität des μC weitgehend unabhängig vom Takt hinkommen. Bei den Neopixel/WS2812b hingegen ist’s Timing kritisch: Dass das ohne Anpassungen nicht funktioniert, sollte jedem klar gewesen sein, der mal geschaut hat, wie die Dinger eigentlich zu benutzen sind. Empfehle ich eigentlich jedem – die Dinger sind ein dankbares Ziel für Versuche, es mal so richtig von Null an selbst zu versuchen → das ist dann ein Schritt mehr raus aus der Abhängigkeit von Arduino und dessen Libs. Wenn man hingegen bei Arduino bleiben möchte, wogegen ja auch nichts einzuwenden ist, sollte man’s vielleicht bei den dort weiter verbreiteten und damit besser berücksichtigten μC belassen.
Jack V. schrieb: > In der Regel ist das so; das im Eingangsbeitrag genannte Display > (besser: dessen Controller) steuert der geneigte Arduinobastler aber > meist mit I²C an, und da sollte man mit der Funktionalität des μC > weitgehend unabhängig vom Takt hinkommen. Nur unterscheidet sich der I2C-Controller des AVR128 erheblich von den klassischen ATmega, wie auch die Timer. Ohne eine komplett neue Lib geht also nichts. Die einzige Gemeinsamkeit ist nur noch der Befehlssatz, also reine Softwarefunktionen laufen unverändert.
Die Frage kann man ganz einfach beantworten. Der Controller ist einfach nicht kompatibel aktuell zum Arduino Framework. Er ist intern am ehesten mit den Atmega Controllern der Null-Serie zu vergleichen. Es wäre ein Versuch wert, ihn als 4809 Arduino in der IDE anzugeben. Wird aber vermutlich auch erfolglos sein.
Aloysius P. schrieb: > Die Frage kann man ganz einfach beantworten. Der Controller ist einfach > nicht kompatibel aktuell zum Arduino Framework. Ich kenne mich mit Arduino nicht sonderlich aus, aber behebt https://github.com/SpenceKonde/DxCore dieses Problem nicht? Edit: soweit ich das überblicke, sollte das doch auch TWI/I²C über die „normalen“ Arduino-Funktionen nutzbar machen? https://github.com/SpenceKonde/DxCore/tree/master/megaavr/libraries/Wire
:
Bearbeitet durch User
Jack V. schrieb: > Aloysius P. schrieb: >> Die Frage kann man ganz einfach beantworten. Der Controller ist einfach >> nicht kompatibel aktuell zum Arduino Framework. > > Ich kenne mich mit Arduino nicht sonderlich aus, aber behebt > https://github.com/SpenceKonde/DxCore dieses Problem nicht? Moin, Ich kenne jemand, der sich ausgiebig mit diesem Bord Package befasst hat und man kann also damit im IDE gut damit umgehen. Für die meisten Projekte sollte es also keine Schwierigkeiten geben. Ob es perfekt ist, wer weiß. Jedenfalls lohnt es sich mit diesem Package zu arbeiten. Pauschal kann man nicht gut kommentieren. Da wäre es besser, spezifisch aufzulisten was nicht zu funktionieren scheint und näher untersuchen. Auch wird kontinuierlich daran verbessert. Man tut wahrscheinlich gut, dort regelmäßig reinzuschauen, damit man sich bezüglich der Änderungen im Laufenden halten kann. Jedenfalls finde ich, daß der DB ein feines Teil ist und wesentlich anspruchsvoller als frühere AVRs in Sachen Peripherie ist. Gerhard
Gerhard O. schrieb: > Jedenfalls finde ich, daß der DB ein feines Teil ist und wesentlich > anspruchsvoller als frühere AVRs in Sachen Peripherie ist. Wesentlich anspruchs-erfüllender würde ich korrigieren wollen. Das periphär meiste funktioniert höchstens etwas anders.
:
Bearbeitet durch User
Sebastian H. schrieb: > Das habe ich aus dem Grund getan, da dieser eine > Taktgeschwindigkeit von 24 MHz und somit eine Höhere Taktgeschwindigkeit > wie die anderen AVR Prozessoren besitzt. Ich muß zugeben, ich bin mit den ATmega bei meinen Projekten noch lange nicht an irgendwelche Grenzen gestoßen, so daß ich einen MC mit noch mehr Bells & Whistless benötigen würde. Auch der Sprung von 16MHz zu 24MHz ist nicht sonderlich gewaltig, zumal vieles schon bei 1MHz schnell genug ist. Und auf Arbeit geht eh alles zu 32Bit (NXP LPC-Serie). Keinerlei Chance, den AVR128 im Altium anzulegen.
Peter D. schrieb: > Und auf Arbeit geht eh alles zu 32Bit Das wär auch dem Arduino Anwender zu raten, der kleine Sprung auf die neuesten AVRs (mitsamt aller Lib-Probleme) lohnt hier nicht wirklich. Peter D. schrieb: > Ich muß zugeben, ich bin mit den ATmega bei meinen Projekten noch lange > nicht an irgendwelche Grenzen gestoßen, Ich auch nicht. Die sind mit Arduino & Co. aber wesentlich schneller erreicht. Vor allem deshalb meine obige Empfehlung.
:
Bearbeitet durch User
Sebastian H. schrieb:
Die Fehlerbeschreibung ist völlig unbrauchbar. "Eine Bibliothek lässt
sich nicht flashen", das gibt es nicht: Man kann beliebige Daten flashen
oder aber gar keine, im letzteren Fall liegt es nicht an den Daten (zu
denen Bibliotheken gehören), sondern an den Vorgängen beim Flashen.
Also erstmal genau mitteilen, wo genau es hakt und welche
Fehlermeldungen kommen.
Lässt sich dein Programm compilieren?
Lässt es sich linken?
Danach erst kommt das Flashen.
Und dann erst das Starten des Programms.
Peter D. schrieb: > Sebastian H. schrieb: >> Das habe ich aus dem Grund getan, da dieser eine >> Taktgeschwindigkeit von 24 MHz und somit eine Höhere Taktgeschwindigkeit >> wie die anderen AVR Prozessoren besitzt. > > Ich muß zugeben, ich bin mit den ATmega bei meinen Projekten noch lange > nicht an irgendwelche Grenzen gestoßen, so daß ich einen MC mit noch > mehr Bells & Whistless benötigen würde. Auch der Sprung von 16MHz zu > 24MHz ist nicht sonderlich gewaltig, zumal vieles schon bei 1MHz schnell > genug ist. Sehe ich genauso. Die Home Computer der 80er waren dagegen lahme Mühlen. Trotzdem, auch mit den konnte viel ausgereizt werden. > > Und auf Arbeit geht eh alles zu 32Bit (NXP LPC-Serie). Keinerlei Chance, > den AVR128 im Altium anzulegen. Wie meinst Du das bitte? Ich habe schon einige Bords mit dem AVR128DB in Altium durchgezogen. Im Zeitalter von Multi-GHz Prozessoren mögen 16MHz TaktrateN bei AVRs ZWAR als lächerlich langsam anmuten, trotzdem sollte man sich im Kontext von Steueranwendungen immerhin vor Augen halten, daß im Mittel fast 16 Millionen Instruktionen pro Sekunde abgearbeitet werden können. Das ist beträchtlich mehr als die früheren Z80 und 8085 u.ä. jener Ära konnten. Also lässt sich mit diesem Ausgangskriterium schon etwas anfangen. Jedenfalls tut es der ATMEGA fein in meinem Interessenbereich. Dasselbe gilt im großen und ganzen für die größeren PICs. Jedenfalls mußte ich noch nie einen uC taktmäßig überziehen. Ich sehe prinzipiell immer noch ein großes Anwendungsgebiet für 8-Bitter. In der Arbeit werkeln wir hauptsächlich mit STM32 wie z.B. den L496, oder LPC von NXP. Aber die Komplexität der cube Peripheral Frameworks ist schon schockierend im Vergleich zu den sauberen einfachen Einstellungen bei den kleineren uC. Irgendwie finde ich die 8-Bitter entspannender für Hobby Spielerei. Da kann man sich Dank des besseren Überblicks viel angenehmer austoben. Mit dem 1284er befasse ich besonders gern. Auch die DB haben ihren Reiz und können noch mehr, was Peripherie angeht. Das ist halt mein Spielplatz. Da ich nichts mit Netz, Lora, Iot mache, brauche ich nicht die höhere Leistung der dort gebräuchlichen Controller. Ist halt eine rein persönliche Ansichtsache. Man soll froh sein, daß sich jeder den uC seiner Wahl und Leistungsbereich aussuchen kann. Eine pauschale Abschreibung der 8-Bit Technik finde ich ohnehin irgendwie unangebracht. Sicherlich, vielleicht schreibt die Industrie in weiteren 25 Jahren 8-Bit Technik komplett ab. Kann passieren. Das wäre dann eher der pathologischen krampfhaften Netzanschluß-Sucht zuzuschreiben, die von den in der Cloud lebenden wahnsinnigen Datenkraken gefordert wird. Die Datensammlerei ist dort die geldmachendwollende Drogensucht der Großfirmen. Ich empfinde es übrigens als bodenlose Frechheit, daß sich die Hersteller einbilden, das jedes Haus- und Küchengerät mit der Cloud verbunden sein sollte. Es geht niemanden etwas an, was ich mit Kühlschrank, Toaster und WaMa mache. Es geht auch niemanden an, wie ich meinen TV verwende. Ich würde es übrigens gar nicht so cool finden, andauernd mein Smartphone aus der Tasche ziehen zu müssen, um triviale Einstellungen damit vornehmen müsste, weil man billigerweise Frontplattenbedienelemente einsparen wollte. Nur aus dem Grund, werden 8-Bitter langsam verdrängt. Die meisten Geräte spezifischen Aufgaben können ohne diesen Faktor nämlich 8-Bitter sonst noch recht gut erfüllen. Was diese Thematik zeigt, ist, daß ein bodenloser Abgrund zwischen großen Segmenten der potentiellen Kunden und der Industrie herrscht. Man kann es offensichtlich nicht mehr allen recht machen, weil die Ziele und Ansprüche oft so kontrovers sind. Gerhard
:
Bearbeitet durch User
Nun das kommt immer darauf an was man braucht. Braucht man eine ZCD so sind die AVR DA‘s ne gute Wahl. Haben die Atmegas und die STM‘s nicht, soweit ich weiss. Ich fand das ganz praktisch bei einem Project.
Rolf schrieb: > Man kann beliebige Daten flashen oder aber gar keine, im letzteren Fall > liegt es nicht an den Daten (zu denen Bibliotheken gehören), sondern an > den Vorgängen beim Flashen. Wieso flashen? Der TO will doch falschen! LG, Sebastian
Hallo, ZCD ... Zero Cross Detection
Sebastian H. schrieb:
wenn du deinen Thread nicht moderierst, kannst du keine Hilfe bekommen.
Das sollte dir schon klar sein. Die entscheidenden Nachfragen wurden von
unterschiedlichen Leuten gestellt. Ohne Antworten darauf geht es nicht
weiter.
Peter D. schrieb: > Veit D. schrieb: >> ZCD ... Zero Cross Detection > > Was stört Dich denn am analog Komparator? Bist du nicht mal mehr in der Lage, der Funktionsbeschreibung der ZCD-Einheit im DB zu entnehmen, was sie besser kann als ein stumpfblöder Komparator? Früher(tm) hast du wirklich noch was sinnvolles geschaffen. Aber ungefähr seitdem du die Benutzung von Assembler zugunsten ausschließlich C aufgegeben hast, kam wirklich nix brauchbares mehr. Du rührst nur noch in der Urscheiße der Classic-AVRs rum und beschränkst dich dabei auch noch auf das, was bei diesen Targets mit C möglich ist. Scheinbar geistiger Overflow. Alterserscheinung. Wird mir auch passieren, soviel ist ziemlich sicher. Aber zum Glück jetzt noch nicht. Wenn auch bei mir bereits deutliche Anzeichen der altersbedingt verringerten Lernfähigkeit zu bemerken sind. Aber der Knackpunkt, ab dem garnichts wirklich neues mehr geht, ist bei mir offensichtlich noch nicht erreicht.
Ob S. schrieb: > Du rührst nur noch > in der Urscheiße der Classic-AVRs rum Warum sollte er auch nicht: Peter D. schrieb: > ich bin mit den ATmega bei meinen Projekten noch lange > nicht an irgendwelche Grenzen gestoßen Die sind halt sehr leistungsfähig, wenn man sie nicht gerade mit vielschichtig abstrahierender Codesch... , Mathematik und zuvielen Daten vollstopft! Allerdings könnte man wirklich mal die neuen AVRs zur Kenntnis nehmen. Dafür haben sie zuviele Vorteile, ohne wirklich komplizierter zu sein.
:
Bearbeitet durch User
Ob S. schrieb: > Bist du nicht mal mehr in der Lage, der Funktionsbeschreibung der > ZCD-Einheit im DB zu entnehmen, was sie besser kann als ein stumpfblöder > Komparator? Komisch, selbst Michrochip scheint diese spezielle ZCD-Einheit nicht zu kennen (App-Note AVR182): https://ww1.microchip.com/downloads/en/Appnotes/Atmel-2508-Zero-Cross-Detector_ApplicationNote_AVR182.pdf Manches ist eben so simpel, daß sich eine dedizierte Hardware nicht lohnt. Ich hab einige Projekte, die sauber die 50/60Hz Phase erkennen und variabel verschieben. Läuft auf ATtiny25, mehr braucht es nicht. Um Störungen zu unterdrücken, läuft es als 55Hz-PLL, die dann auf 50Hz bzw. 60Hz einrastet und jeweils um den gleichen prozentualen Phasenwinkel verschiebt. Damit sind selbst Rundsteuersignale kein Problem.
Peter D. schrieb: > Komisch, selbst Michrochip scheint diese spezielle ZCD-Einheit nicht zu > kennen (App-Note AVR182): Vielleicht solltest Du dazu mal an den richtigen Stellen suchen. Die finden sich aber nicht in alter Atmel-Dokumentation sondern in jener neuerer Microchip-AVRs, z.B. Aloysius P. schrieb: > Braucht man eine ZCD so sind die AVR DA‘s ne gute Wahl. Gerhard H. schrieb: > Allerdings könnte man wirklich mal die neuen AVRs zur Kenntnis nehmen
:
Bearbeitet durch User
Peter D. schrieb: > Manches ist eben so simpel, daß sich eine dedizierte Hardware nicht > lohnt. Kommt drauf an. Natürlich kann man das, was die ZCD in Hardware zusätzlich zum Komparator erledigt, auch in Software realisieren. Darüber brauchen wir uns nicht zu streiten. > Ich hab einige Projekte, die sauber die 50/60Hz Phase erkennen und > variabel verschieben. So what, ich auch. Damals(tm) ging's halt nicht anders. Aber wenn man für erweiterte Funktionalität noch ein wenig Rechenleistung (oder Interruptlatenz) freischaufeln muss, dann können auch die natürlich recht primitiven ZCDs durchaus hilfreich sein. Da hast einfach nie mit Sachen zu tun gehabt, in denen der µC tatsächlich bis nahe an seine Grenzen ausgelastet wird. und das dann zum Anlass genommen, um zu sagen: das brauch' ich nicht mehr lernen, das nützt mir nix.
Ob S. schrieb: > µC tatsächlich bis nahe an seine Grenzen ausgelastet Es geht längst nicht nur um Auslastung sondern einfach Vorteile wie einfacheres Programmieren/Debuggen, 12Bit ADC Auflösung, höhere Genauigkeit des internen Takts, mehr Takt bei weniger Spannung, mehr Flash und RAM in kleineren Bauformen, unabhängiges Event-System und und und... Diese Vorzüge zu nutzen dafür muß man beim Schritt alte>neue AVRs wirklich kaum Ob S. schrieb: > mehr lernen
:
Bearbeitet durch User
Ich hab auch oft alten C51 Code auf anderen MCs wieder verwendet. Z.B. generisches I2C, SPI mit einfachen IO-Pins. Das spart deutlich Arbeit gegenüber jedesmal den Code für die Hardware-Einheiten anderer MCs umschreiben zu müssen. Und solange es nicht im Hintergrund über Interrupts nötig ist, sparen die Hardware-Einheiten weder deutlich CPU-Zeit noch Flash ein. Bzw. der Code wird sogar größer, wenn man sämtliche Bells & Whistles behandelt. Neue Hardware kostet eben nicht unerheblich Zeit, die man im Alter immmer weniger bereit ist, zu investieren. Ich bin da auch ein gebranntes Kind, bei neuer Hardware erstmal die Bugs und Doku-Fehler finden zu müssen. Meine Erfahrung ist leider, daß gemeldete Bugs kaum noch behoben werden und oft nicht mal mehr dokumentiert. Es ist schon frustrierend, wenn man aus der Antwort merkt, daß der Supportheini den Testcase nichtmal ausprobiert hat. Gerhard H. schrieb: > Vielleicht solltest Du dazu mal an den richtigen Stellen suchen. Ich habe nach "Zero Cross Detection AVR" gesucht.
Ob S. schrieb: > Da hast einfach nie mit Sachen zu tun gehabt, in denen der µC > tatsächlich bis nahe an seine Grenzen ausgelastet wird. Das stimmt natürlich. Wenn ich ein Projekt bei 16MHz habe, dann schalte ich abschließend mal den Prescaler ein, ob bei 8MHz alles immer noch stabil läuft, quasi Hosenträger mit Gürtel.
Peter D. schrieb: > Veit D. schrieb: >> ZCD ... Zero Cross Detection > > Was stört Dich denn am analog Komparator? Nichts. Ich hatte nur übersetzt was von Aloysius undeutlich geschrieben und von Anderen nachgefragt wurde. ;-)
Peter D. schrieb: > Ich habe nach "Zero Cross Detection AVR" gesucht. Das ist ein neues Peripherie Modul. Ein Blick ins Inhaltsverzeichnis der Datenblätter etwa eines AVR-Dx hätte gereicht. Peter D. schrieb: > Und solange es nicht im Hintergrund über Interrupts nötig ist, sparen > die Hardware-Einheiten weder deutlich CPU-Zeit noch Flash ein. Bzw. der > Code wird sogar größer, > Ich hab auch oft alten C51 Code auf anderen MCs wieder verwendet. Z.B. > generisches I2C, SPI mit einfachen IO-Pins. Das spart deutlich Arbeit Das klingt nicht unbedingt nach professioneller Programmierung sondern eher nach Weg des geringsten Widerstands. Trotzdem, wer bin ich Deine langjährige Erfahrung hier abschließend zu beurteilen. Wer aber ernsthaft zu dem Schluß kommt, (neue) Hardware-Peripherie ließe sich nicht gewinnbringend einsetzen, da stimmts für mich an irgendeinem Punkt der Kette ganz grundsätzlich nicht. Das entschuldigt selbst > Ich bin da auch ein gebranntes Kind, bei neuer Hardware erstmal die Bugs > und Doku-Fehler finden zu müssen. Meine Erfahrung ist leider, daß > gemeldete Bugs kaum noch behoben werden und oft nicht mal mehr > dokumentiert. nicht, weil Du hier - den Fehlerlevel zu hoch hängst - ignorierst daß andere Leute offensichtlich dennoch fähig sind damit wunderbar zu programmieren - ignorierst, daß die neue AVR-Hardware von Microchip inzwischen lang genug auf dem Markt ist um die Qualität zu überblicken. Noch dazu in Zeiten des Internets, das fast jeden Sachverhalt und Mangel nur einen Mausclick und Suchbegriff entfernt behandelt. Hardwarefehler, suboptimale Dokumentation und Support hats immer gegeben. Es klingt daher alles eher wie eine Ausrede. Das denke ich mir regelmäßig wenn Du hier nach Begründungen suchst, Dich neuer Hardware zu verweigern. Noch dazu solcher, die eine bekannte Architektur nur maßvoll, begrenzt und evolutionär weiterentwickelt statt von grundauf umzusatteln.
:
Bearbeitet durch User
Hallo Gerhard, Ich glaube, Du tust dem Peter Unrecht und Deine Kritik trifft nicht unbedingt ins Schwarze. So wie ich Peters Vergangenheit hier mitkriege, habe ich den Eindruck, daß er 100%ig weiß von was er spricht und kann es mit jahrerlanger Labor- und Industrieerfahrung belegen, wo man allerhand erleben kann. Ich bin (vielleicht genauso wie er) der Meinung, daß der Feind, den man kennt, weniger gefährlich ist. Auf Technik bezogen, sagt das nicht mehr oder weniger aus, daß es schon Sinn hat, aus schon gemachten Projekterfahrungen zu schöpfen und Wiederverwendbarkeit vorhergegangener Arbeit bestmöglich auszunützen, um unnötiges kostspieliges Risiko gering zu halten und Zeit zu sparen. Im professionellen Umfeld gilt ganz besonders "Time is Money". Innovation ohne greifbare Vorteile ist am Ende dann doch nur narzisstische Spielerei. Nicht jeder Entwickler befasst sich mit "cutting edge" Technik und risikovolle Innovation. Viel Arbeit muß auch in schnöde, nicht-scheinende und blitzende "Gebrauchstechnik" in Industrie und wichtigen Techniksparten reingesteckt werden, die man am Besten mit bewährten Methoden angeht. Persönliche Egotrips schaden am Ende hier nur. Wie oft schon, wurde in Firmen und Institutionen unheimlich Geld verprasst, weil man dann doch dem unbelegten Hype verfiel und noch unerfahrenen Verfechtern und Ideenverkäufern glaubte, die die Welt versprachen und es am Ende doch nichts nützte und viel Geld verprassten. Erfinder mit Vision, müssen genug Erfahrung haben, um ihre Erfolgschancen realistisch abschätzen zu können. Daran fehlt es oft. Man braucht ja nur zu Messen gehen, wo viel technischer Unfug vorgezeigt wird, der gleich wieder vergessen wird. Um auf neueste Technik Möglichkeiten zu setzen bedingt es einen gewissen Weitblick und zukünftige mögliche Vorteile und Möglichkeiten zu erkennen. Nur dann hat es Sinn, sich damit zu befassen. Wer, wie die meisten, nutzvolle Technik ins Leben rufen muß, tut besser daran, sich auf die schon gemachten Erfahrungen und den sicheren Weg einer schon als verläßlich angesehenen Techniklösungen zu bleiben, wo man sich die Hörner schon abgestossen hat. Innovation ohne wirkliche Substanz enttäuscht am Ende nur. Ja, ich weiß, manche von Euch werden jetzt lächeln und sich ihren Teil über mich denken. Das macht nichts. Das dürfen sie. Im Forum darf man ja seine Meinung zum Besten geben😊 So, lieber Gerhard, jetzt wirst Du gelesen haben, wie ich alter Hund, mit zahlreichen Beißnarben, über gewisse Sachen denke. Und ja. Auch ich finde die DB AVRs nützlich und habe schon damit gearbeitet. Aber darum geht es hier nicht. Duck und weg, Gerhard
:
Bearbeitet durch User
Gerhard O. schrieb: > daß es schon Sinn hat, aus schon gemachten > Projekterfahrungen zu schöpfen und Wiederverwendbarkeit vorhergegangener > Arbeit bestmöglich auszunützen, um unnötiges kostspieliges Risiko gering > zu halten und Zeit zu sparen. Natürlich macht das Sinn. Macht doch jeder so, der halbwegs des Denkens mächtig ist. > Im professionellen Umfeld gilt ganz > besonders "Time is Money". Innovation ohne greifbare Vorteile ist am > Ende dann doch nur narzisstische Spielerei. Und genau das ist der Fehler, den auch unsere Damager immer wieder machen: Entwicklung? Kostet doch nur Geld! Das geht eine Weile gut. Aber irgendwann ist Ende Gelände. Dann wird es richtig teuer. Oder man ist sogar komplett raus aus dem Deal. Weil sich ein Konkurrent findet, der halt nicht ewig nichts gemacht hat...
Gerhard H. schrieb: > Das klingt nicht unbedingt nach professioneller Programmierung sondern > eher nach Weg des geringsten Widerstands. Ganz im Gegenteil eine vorhandene Codbasis zu benutzen ist sogar sehr professionell. Es zeigt nämlich, das sich der Programmierer vorher Gedanken gemacht hat und den Code bzw. die Schnittstellen so programmiert hat, daß der Code auch an andere Stelle einsetzbar ist. Die Arbeit und das Knowhow stecken halt im Basiscode. Den zu entwickeln war deshalb anfangs etwas aufwendiger, aber es zahlt sich am Ende aus - man kann ihn schnell portieren. Den Anfangs investierten Mehraufwand holt man so schnell wieder rein.
Hans schrieb: > Ganz im Gegenteil eine vorhandene Codbasis zu benutzen ist sogar sehr > professionell. Gewiss. Unprofessionell nenne ich aber, sich neuen Möglichkeiten und Verbesserungen mit genau dieser Begründung zu verschließen. Das führt in der Tat irgendwann zu Ob S. schrieb: > Ende Gelände in der fortwährenden Umstrickung und Anpassung alter Zöpfe an neue Umstände. Nicht mehr, nicht weniger. Darüber hinaus lässt sich ohne genaue Kenntnis der Projekte ohnehin nur spekulieren. Gerhard O. schrieb: > Innovation ohne wirkliche Substanz Na wenn Du meinst. Zumindest über die Vorzüge der neuen AVRs denke ich ganz anders- vor allem aber nutze ich sie ganz konkret und auf breiter Front.
Gerhard H. schrieb: > Gewiss. Unprofessionell nenne ich aber, sich neuen Möglichkeiten und > Verbesserungen mit genau dieser Begründung zu verschließen. Mach Dir mal keine Sorgen, ich kann schon recht gut einschätzen, ob eine Funktionalität der Flaschenhals ist. Und solange sie es das nicht ist, werde ich nicht grundlos neue MCs einführen, um darauf unnütz bestehende Libs neu zu implementieren. Zumal jedes Einführen eines neuen Bauteils einen erheblichen Verwaltungsaufwand kostet. Ich muß also fundiert begründen können, warum das unbedingt notwendig sein soll. Einfach nur so aus Spieltrieb, da würde sich mein Chef an die Stirn tippen und mir einen Arztbesuch empfehlen. Professionell arbeiten heißt eben auch, ökonomisch denken. Ich habe nichts von "Verbesserungen", die vielleicht ein bischen CPU-Last einsparen, aber für den Anwender vollkommen unmerkbar sind.
Peter D. schrieb: > Mach Dir mal keine Sorgen, ich kann schon recht gut einschätzen, ob eine > Funktionalität der Flaschenhals ist. Und solange sie es das nicht ist, > werde ich nicht grundlos neue MCs einführen Damit können wir das denke ich abhaken- selbst wenn es vielleicht doch nicht die ganze Wahrheit sein sollte und mich keinesfalls überzeugt. Da aber der Chef mit diesem technologischen Stillstand zufrieden scheint, was will man da noch groß opponieren! Insofern alles richtig gemacht Peter. Immerhin, Punkt für Dich, ist zwischen unternehmerischer Ökonomie und Freiheit im Hobby ein gewichtiger Unterschied. Was aber manches Deiner in der Vergangenheit hier schon vorgetragenen = vorgeschobenen Argumente gegen neuere MC-Technik nicht überzeugender macht. > Ich habe nichts von "Verbesserungen", die vielleicht ein bischen > CPU-Last einsparen Ich hatte doch nun schon mehrfach angemerkt, daß es längst nicht nur um CPU-Lasten oder Speicherverbräuche sondern um viele weitere, ganz handfeste Vorteile neuerer Hardware geht. Und würde fast wetten, daß es auch bei Euch Projekte gäbe die davon eindeutig profitieren könnten. > Zumal jedes Einführen eines neuen Bauteils einen erheblichen > Verwaltungsaufwand kostet. Über solche Widerstände kann man doch (als freier Hobbyist) wirklich nur den Kopf schütteln.
:
Bearbeitet durch User
Gerhard H. schrieb: > Und würde fast wetten, daß es > auch bei Euch Projekte gäbe die davon eindeutig profitieren könnten. Ich hab mich ja schonmal gewundert, warum in kurzer Folge die 0-, 1-, 2- Tinys mit nur minimalen Änderungen rausgebracht wurden. Ich konnte es mir nur so erklären, daß sich damit neue Besen profilieren wollten. Angeschaut habe ich mir also die neuen Typen durchaus. Bahnbrechende Neuerungen habe ich allerdings keine gefunden. Daß die neueren AVR-Typen allesamt keinen CAN-Bus haben, ist jedoch ein beträchtlicher Nachteil. Somit scheiden sie für uns aus. Der AT90CAN128 ist daher bei vielen Projekten unser Arbeitspferd. Ein neuer AVR mit 8 Pins (CAN + 4 IOs) und internem CAN Transceiver wäre mal was was wirklich interessantes. Den größten Zeitaufwand bei der Entwicklung brauchen aber nicht irgendwelche Hardware-Gimmicks, sondern die Entwicklung neuer Algorithmen und Abläufe.
:
Bearbeitet durch User
Peter D. schrieb: > Daß die neueren AVR-Typen allesamt keinen CAN-Bus haben Das ist richtig. Damit hast Du aber wirklich just das einzige Interface getroffen welches den neuen noch fehlt. USB wurde ja nun mit den AVR64DU nachgereicht. Vielleicht kommt CAN noch, vielleicht ist man ja der Meinung, daß der Standard schon überholt ist? Die Welt gehört schließlich zunehmend drahtloser Kommunikation- entsprechende AVRs würde ich mir noch wünschen... > Den größten Zeitaufwand bei der Entwicklung brauchen aber nicht > irgendwelche Hardware-Gimmicks, sondern die Entwicklung neuer > Algorithmen und Abläufe. Natürlich. Was aber nach wie vor nichts an der Vorteilhaftigkeit vieler Vorteile ändert :) > Bahnbrechende Neuerungen habe ich allerdings keine gefunden. Ach was. Z.B. das neue Programmier/Debug Interface ist für mich eine solche! Hast Du damit überhaupt schon Kontakt gehabt? Was ist für Dich denn "bahnbrechend"? Große Brüche in der Kompatibilität wären jedenfalls das letzte was man sich wünschen kann. Und nein, das bischen Änderung in mancher Peripherie-Ansteuerung zähle ich ausdrücklich nicht dazu! Auch wenn es hier dem TO vermutlich gerade in Bibliotheks-Form Probleme macht. Die Arduino- Zukunft wird sicher nicht 8bittig daherkommen. Dafür drängen sich viel leistungsfähigere Plattformen geradezu auf. Da darf gerne noch reichlich Ingenieurs-Gehirnschmalz investiert werden. Den Erfolg würde ich aber daran bemessen, ob Arduino einfach und zugänglich bleibt, seine Rolle als Mittler zwischen komplexerer Hardware und unbedarftem Anwender weiter so spielen kann. Ich habe da meine leisen Zweifel.
:
Bearbeitet durch User
>Die Arduino- Zukunft wird sicher nicht 8bittig daherkommen. Dafür >drängen sich viel leistungsfähigere Plattformen geradezu auf. Da darf >gerne noch reichlich Ingenieurs-Gehirnschmalz investiert werden. Den >Erfolg würde ich aber daran bemessen, ob Arduino einfach und zugänglich >bleibt, seine Rolle als Mittler zwischen komplexerer Hardware und >unbedarftem Anwender weiter so spielen kann. Ich habe da meine leisen >Zweifel. Da wäre die Frage, was Arduino überhaupt ist. STM hat sich hier längst verselbständigt und ist ohnehin leistungsfähiger: https://github.com/stm32duino/Arduino_Core_STM32
Gerhard H. schrieb: > Ach was. Z.B. das neue Programmier/Debug Interface ist für mich eine > solche! JTAG funktioniert doch beim AT90CAN. Ich muß nicht ständig mit neuen Tools rumspielen, nur so aus Langeweile. Allerdings floaten meine MCs oft auf gefährlichen Spannungen (bis 15kV). Daher erfolgt Flashen und Debuggen vorwiegend über CAN + Ethernet. USB wird im industriellen Umfeld nicht gerne gesehen, es hat so mancher über Erdschleifen seine USB-Geräte zerstört. Ich hab doch überhaupt nichts dagegen, daß Du die neueren Typen verwendest. Aber tue bitte nicht so, als würde man etwas wichtiges verpassen, wenn man sie nicht einsetzt. Und auf keinen Fall hat man dann irgendwelche Wettbewerbsnachteile.
:
Bearbeitet durch User
Peter D. schrieb: > Und auf keinen Fall hat man dann irgendwelche Wettbewerbsnachteile. Dann ist ja gut wenn das bei Euch gilt. Ich wäre nur sehr vorsichtig, das (aus einer Nische heraus?) zu pauschalieren und für alle Zeiten festzuschreiben. Viel Erfolg dabei. Daß die Industrie ein ziemliches Beharrungsvermögen beim Betrieb von Technik hat (und oft haben muß) kenne ich aus eigener Anschauung. Der Zweck heiligt die alten Mittel. Doch die Konkurrenz schläft nicht. Irgendwann kann dann plötzlich alles ganz schnell aus sein. Du könntest aber Recht haben Peter daß es an Unterschieden innerhalb der 8Bit Controllerklasse nicht scheitern wird :)
:
Bearbeitet durch User
Peter D. schrieb: > Ich muß zugeben, ich bin mit den ATmega bei meinen Projekten noch lange > nicht an irgendwelche Grenzen gestoßen, so daß ich einen MC mit noch > mehr Bells & Whistless benötigen würde. Auch der Sprung von 16MHz zu > 24MHz ist nicht sonderlich gewaltig, zumal vieles schon bei 1MHz schnell > genug ist. Aber man bekommt diese 24 MHz schon ab VCC 1,8 Volt! Ich habe gerade mit AVR128DB-Serie begonnen. Es gibt einiges, was für mich viel Wert hat: 1. 24 MHz wie gesagt schon ab 1,8 Volt VCC. 2. 4 oder 8 Pins, die andere VCC haben dürfen. Z.B. Mikrocontroller selbst läuft mit 3,3 Volt, aber einige Geräte werden mit 5 Volt gespeist. Und das ohne Pegelwandler. 3. reiche Peripherie. Z.B. man kann zwei 16 bit Zähler zusammen koppeln und somit 32 bit Zähler haben, ohne ISR usw., einfach so. 12 bit ADC, 10 bit DAC. Mehrere USARTs, zwei SPI. 3. Sicherere Arbeit. Nun ist nicht mehr möglich, Mikrocontroller durch falsche Sicherungen kaputt zu machen, da immer mit internen Takt gestartet wird und erst dann gewechselt. Einiges hat Hersteller endlich gemacht, was schon von Anfang an sein sollte. Z.B. nun haben ALLE Ports eine Adresse in Bit-Raum, wo man sie mit sbi und cbi erreicht. Bei ATMega2560 ist das leider nicht immer so. Und überhaupt mehr Möglichkeiten für Arbeit mit Pins. Flash ist nun teilweise mit lds zu erreichen, auch sehr bequem. Nur ein Minus: volle Version mit 64 Pins ist schwerer zu löten, da nur 0,5 mm zwischen Pins. Noch etwas, was mir nicht gefiel: in ersten PDF für AVR128DB steht wie für meisten MEGA auch 10 000 Flashprogrammierungen. In erneuerten PDF steht aber nur 1000 Mal.
:
Bearbeitet durch User
Gerhard H. schrieb: > Dann ist ja gut wenn das bei Euch gilt. > Ich wäre nur sehr vorsichtig, das (aus einer Nische heraus?) zu > pauschalieren und für alle Zeiten festzuschreiben. Du darfst gerne die ultimative Killeranwendung beschreiben, die zwingend einen der neueren AVRs benötigen würde. Ich sehe sie nirgends. Allgemein sehe ich kein Potential, die AVRs noch weiter pimpen zu wollen. Sobald ich merken sollte, daß meinem AVR die Puste ausgeht, dann werden weitere Hardwareeinheiten ihm auch nichts nützen. Dann geht es eben zu Cortex 32Bit und Mehrkerner (z.B. M0 + M4).
Maxim B. schrieb: > in ersten PDF für AVR128DB steht wie für meisten MEGA auch 10 000 > Flashprogrammierungen Mutmaßlich einer der vielen Copy & Paste Fehler beim Übertragen von Passagen aus alten Datenblättern. Der Mega128 etwa hatte noch 10000. Alle neueren 1000. Aber Hand aufs Herz- das langt genauso. Peter D. schrieb: > Sobald ich merken sollte, daß meinem AVR die Puste ausgeht, dann werden > weitere Hardwareeinheiten ihm auch nichts nützen. Du hast Dich eben noch nie mit neueren Features wie dem Event-System befasst. > Du darfst gerne die ultimative Killeranwendung beschreiben, die zwingend > einen der neueren AVRs benötigen würde. Ich sehe sie nirgends. Albern Du bist. Das fängt doch schon bei mehr ADC Auflösung an... Doch ich ahne schon, die brauchst Du nicht. Nirgends in Deinem Universum. > Dann geht es eben zu Cortex 32Bit und Mehrkerner (z.B. M0 + M4). Die Portierung des hochgelobt vorhandenen eigenen Codes auf völlig neue Architektur ist ja auch keinen Deut komplizierter. Wird denn Dein alleiniges Killerkriterium CAN dort in der Weise unterstützt wie Du es brauchst?
:
Bearbeitet durch User
12 Bit ADC gibt es bei CM schon seit Ewigkeiten, inkl. DMA. Toller Meilenstein bei den AVR, schön wer über 10 Jahre Zeit hatte darauf zu warten. Was wird in 10 Jahren erfunden, Ethernet NIC im Controller? Auch für (Dual) CAN gibt es reichlich Auswahl. Man muss schon eine ganz schön rosarote Brille aufhaben CAN als obsolet anzusehen. Heimisches Bastelfeld ist etwas anderes als Automotive und Industriell.
J. S. schrieb: > Heimisches > Bastelfeld ist etwas anderes als Automotive und Industriell Da hast Du sicher Recht. Insbesondere glänzt das heimische Bastelfeld mit Freiheiten von denen man in der Industrie nur träumen kann. > Man muss schon eine ganz > schön rosarote Brille aufhaben CAN als obsolet anzusehen. Noch nicht obsolet ja. Aber die Zukunft? Wer das glaubt trägt die berüchtigte Brille viel eher. > Toller > Meilenstein bei den AVR, schön wer über 10 Jahre Zeit hatte darauf zu > warten. Ja, ein toller Meilenstein. Gerade weil 8Bitter recht stiefmütterlich weiterentwickelt werden. Eben deshalb die Begeisterung. So ein simpel programmierbarer 8Bitter mit >100 MHz, mehreren Kernen und Hunderten KB Flash und RAM- das wär mal was, das bringt meine Augen zum Leuchten! Nur: In welcher Relation stünde das zu den typischen Einsatzzwecken dieser Controller?
Gerhard H. schrieb: > Doch > ich ahne schon, die brauchst Du nicht. Stimmt, ich benutze externe 16Bit ADC (MAX1300) und DAC (AD5668). Das erleichtert es auch sehr, digitale Störungen vom Analogteil fernzuhalten. Gerhard H. schrieb: > Wird denn Dein alleiniges Killerkriterium CAN dort in der Weise > unterstützt wie Du es brauchst? Ein Kollege hat den CAN-Code für AT90CAN128, LPC4357 geschrieben und ich linke ihn nur hinzu. Gerhard H. schrieb: > Du hast Dich eben noch nie mit neueren Features wie dem Event-System > befasst. In den AVR Projekten wird es nicht benötigt. Aber beim LPC4357 benutzen wir es.
Peter D. schrieb: > ich benutze externe 16Bit ADC (MAX1300) und DAC (AD5668). Und mit controller-internem ADC/DAC hast Du eben den Luxus, auf externe ICs verzichten zu können. Wenn denn Auflösung/Leistung und Störabstand genügen. Daß man da mit einem AT90CAN nicht weit kommt ist logisch. Womöglich würde den Anwendungen aber hier doch schon ein neuer AVR reichen? Mal ganz frech gefragt. Das dürfte dann sogar ziemlich Aufwand und Kosten sparen. > In den AVR Projekten wird es nicht benötigt. Aha. Es wird "nicht benötigt". Was ändert das am vorhandenen "Puste"-Angebot? Überhaupt frage ich mich, warum Ihr nicht längst auf ARM umgestiegen seid. Was bringt die doppelte Architektur-Schiene noch? Denn bei ARM gibt es bekanntlich nicht nur J. S. schrieb: > für (Dual) CAN ... reichlich Auswahl sondern sicher auch noch andere leistungsfähigere Peripherie (ADC/DAC) ?!?
:
Bearbeitet durch User
Gerhard H. schrieb: > Und mit controller-internem ADC/DAC Welchen MC mit 8*16Bit ADC und 8*16Bit DAC könntest Du mir empfehlen? Am MAX1300 gefällt mir besonders, daß er bis +/-16V verträgt. Gerhard H. schrieb: > Aha. Es wird "nicht benötigt". Was ändert das am vorhandenen > "Puste"-Angebot? Verstehe ich nicht. Wenn die CPU viel berechnen und auswerten muß, ändert ein Event-System nichts daran. Es hilft nur in dem Spezialfall, wenn sehr viele IO-Zugriffe nötig werden, z.B für einen Patterngenerator.
:
Bearbeitet durch User
Georg M. schrieb: > Arduino UNO R4: > > https://www.renesas.com/us/en/document/dst/renesas-ra4m1-group-datasheet?r=1054146 Vielversprechend. Und das Ding wird schon vollumfänglich über die Arduino-IDE unterstützt? Peter D. schrieb: > Welchen MC mit 8*16Bit ADC und 8*16Bit DAC könntest Du mir empfehlen? Was die ARM-Welt da bereithält kann ich Dir nicht sagen. Meine Vermutung zielte ja dahin daß es vielleicht schon mit 12 Bit (und ein paar weniger Kanälen) gehen könnte!? Fürs fehlende CAN bieten sich immer noch CAN Interface-ICs an. Aber nochmal: Warum kein kompletter ARM-Umstieg? Das gilt insbesondere für > Wenn die CPU viel berechnen und auswerten muß Nichtsdestotrotz kann das Event-System die Behandlung vieler I/O Prozesse cpu-unabhängig und schneller machen- spart so die sprichwörtliche Puste. Nix da "nur Spezialfall" ! https://onlinedocs.microchip.com/pr/GUID-C866D457-41E2-43C7-8442-2F1193FAAD9F-en-US-4/index.html?GUID-4833C767-98D0-467C-A41C-9BE5A3C2D233
:
Bearbeitet durch User
Georg M. schrieb: > Arduino UNO R4: > > https://www.renesas.com/us/en/document/dst/renesas-ra4m1-group-datasheet?r=1054146 Moin, interessantes Teil. Wie kann man aber so einen leistungsfähigen MCU nur auf einer so "Gehirn-Amputierten" Plattform wie den UNO R4 einsetzen? Ist eigentlich schade, wenn man sich die "Peripherie-Innereien" und Sonstige Eigenschaften ansieht. Besonders interessant sind übrigens die kryptographischen Eigenschaften. Hat jemand von Euch Erfahrung mit den anderen nicht-Arduino Entwicklungswerkzeugen und Programmierung? Taugt das Renesas e2Studio etwas? Die Frage ist aber, wie lange diese MCU Familie im Lieferprogramm verbleiben wird. Irgendwie fürchte ich für die Lebenserwartung dieser "Eintagsfliegen". Wie steht es mit domestischer Erhältlichkeit und Lieferprioritäten? Ist es besser auf westliche Hersteller zu setzen oder kann man sich in Klein-Produktions-Szenerien auch auf Externe setzen, wenn mindestens 10-20 jährige Lieferbarkeit kritisch ist? Unsere Produkte müssen so lange lieferbar und wartbar sein wegen der ganzen Zulassungen. Für lang-existierende Designs und Produkte kommt mir die Wahl des MCUs immer als eine Art Van banque Spiel vor. Gerhard
Gerhard H. schrieb: > https://onlinedocs.microchip.com/pr/GUID-C866D457-41E2-43C7-8442-2F1193FAAD9F-en-US-4/index.html?GUID-4833C767-98D0-467C-A41C-9BE5A3C2D233 Beispiel Mechanical Button: zum totlachen. Selbst bei viel gutem Willen spart das unter 1% CPU-Last ein. Nee, dafür mache ich kein neues Platinenlayout und schreibe meinen Code nicht um. Ich hätte schon vernünftige Beispiele erwartet und nicht sowas an den Haaren herbei gezogenes. Auf die Killeranwendung warte ich also vergeblich, das war mir aber schon vorher klar.
:
Bearbeitet durch User
Peter D. schrieb: > Ich hätte schon vernünftige Beispiele erwartet und nicht sowas an den > Haaren herbei gezogenes Ich fürchte dafür langt Dein Überblick, mindestens aber der Wille dazu an dieser Stelle der für Dich neuen AVRs längst nicht. Die ARM-Frage bleibt immer noch unbeantwortet. Ebenso, wofür die 2mal8mal16Bit ADC/DAC samt zusätzlicher kostentreibender ICs wirklich gebraucht werden. Nun was solls, es ist nicht meine Aufgabe, hier Deine Designs zu hinterfragen. Optimierungspotential gibts aber immer, mit so einem Uralt-Controller fast sicher :) Gerhard O. schrieb: > Wie kann man aber so einen leistungsfähigen MCU nur auf einer so > "Gehirn-Amputierten" Plattform wie den UNO R4 einsetzen? Ist eigentlich > schade Nein, es ist immer gut eine solch leistungsfähige MCU möglichst vielen Entwicklern zugänglich zu machen. Arduino kann und sollte das tun.
:
Bearbeitet durch User
Beitrag #7631405 wurde vom Autor gelöscht.
Gerhard O. schrieb: > Die Frage ist aber, wie lange diese MCU Familie im Lieferprogramm > verbleiben wird. RA Family: 15 Jahre https://www.renesas.com/us/en/products/microcontrollers-microprocessors/ra-cortex-m-mcus
:
Bearbeitet durch User
Hallo, die Diskussion verläuft schon länger etwas schräg. Oder? Ich drängel niemanden eine neue MCU Generation auf. Nur ist es auf der anderen Seite belustigend wie sich Ausreden entwickeln. Und natürlich werden MCUs innerhalb einer Generation behutsam weiterentwickelt. Denn die gesamte Bandbreite an MCU Varianten gibt es bei jeden Hersteller. Würde er seine kleinste Serie aufbohren wären seine größeren Serien obsolet. Dann kommt der Nächste und heult das es keine "Tinys" mehr gibt. Ihr dreht euch doch alle im Kreis. Es sollte doch für jeden die passende MCU erhältlich sein und gut ist. Wegen Killeranwendung. Die wird es so nie geben. Das definiert jeder anders. Oder denkt jemand Apple hätte für die Vision Pro am Anfang mit einem ATmega4809 rumprobiert bis sie merkten, ne der hat zu wenig Rechenleistung. Nochmal zurück zu den Möglichkeiten, falls einem die Ideen fehlen. Auf die Timerkaskadierung möchte ich nicht mehr verzichten. Man spart sich das umrechnen und beachten von Bitzuständen usw.. Natürlich geht das alles auch ohne, aber es macht es einfacher. Warum soll man darauf verzichten. Wer das nicht will der soll es lassen. Mit dem Eventsystem kann man sich, bspw. beim Arduino Nano Every interessant, fehlende Pins die nicht nach außen geführt wurden, nach außen holen. Mittels Eventsystem kann man alle CCL Bausteine komplett nutzen. Man kann sich mittels Event und CCL externe Logik ICs sparen. Für ein/zwei H-Bridge mit Verriegelung interessant. Wem das alles nicht reicht greift zur größeren MCU und/oder anderen Hersteller oder bleibt beim Altbewährten. Eine Weiterentwicklung sollte man dann aber nicht unnötig klein reden. Dem einem oder anderem ist sie nützlich. Aber wem sage ich das. Ich drängel ja niemanden die Möglichkeiten auf. Wer bin ich den.
Peter D. schrieb: > Gerhard H. schrieb: > Beispiel Mechanical Button: zum totlachen. > Selbst bei viel gutem Willen spart das unter 1% CPU-Last ein. > Nee, dafür mache ich kein neues Platinenlayout und schreibe meinen Code > nicht um. > Ich hätte schon vernünftige Beispiele erwartet und nicht sowas an den > Haaren herbei gezogenes. > Auf die Killeranwendung warte ich also vergeblich, das war mir aber > schon vorher klar. „Da sagte die Erde, ich bin der Mittelpunkt des Universums“ Typisch deutsch. An jeder Ecke selbsternannte und selbstverliebte Nobelpreisträger, mit offensichtlich zu viel Freizeit für sinnlose Diskussionen.
Aloysius P. schrieb: > Typisch deutsch Nun wundere Dich nicht, hier ist Deutschland. > offensichtlich zu viel Freizeit für sinnlose > Diskussionen Du hattest bislang zuwenig, richtig zitieren zu lernen :)
Leute, die ständige Jagd nach der MCU mit den meisten Bells & Whistless führt doch zu nichts. Jede MCU, die alle gestellten Aufgaben voll erfüllt, ist automatisch auch die passende. Ich hatte anfangs auch gerne mal Microoptimierung betrieben, also zuviel Zeit für Sachen aufgewendet, die keine Meilensteine erbrachten. Daß die neuen Features ganz nett sind, gebe ich doch gerne zu. Aber man muß doch andere nicht dazu zwingen oder gar beleidigen. Wenn Gerhard H. nichts sonst weiter kann, als alle die zu beleidigen (unprofessionell, technologischer Stillstand, Ende Gelände usw.), die nicht permanent den längsten haben müssen, dann tut er mir leid.
Peter D. schrieb: > Ich muß zugeben, ich bin mit den ATmega bei meinen Projekten noch lange > nicht an irgendwelche Grenzen gestoßen Das sagt leider mehr über dich und deine Projekte aus, als über den ATmega.
Peter D. schrieb: > Wenn Gerhard H. nichts sonst weiter kann, als alle die zu beleidigen > (unprofessionell, technologischer Stillstand, Ende Gelände usw.), die > nicht permanent den längsten haben müssen, dann tut er mir leid. Na na na Peter, hier muss sich niemand beleidigt fühlen. Du bleibst doch weiterhin ein sehr fachkundiger Foren-Teilnehmer. Ich selber habe sogar einige Deiner früheren Asm-Lösungen noch im produktiven Einsatz. Wo man dann stehen bleibt und wo weitergeht muss jeder selber wissen. Das hängt doch von sovielen individuellen Randbedingungen ab die man hier auch kaum in wenige Sätze packen kann. Mit einem 8Bit Controller hat man definitiv nicht den längsten. Egal welchem :)
:
Bearbeitet durch User
Peter D. schrieb: > Leute, die ständige Jagd nach der MCU mit den meisten Bells & Whistless > führt doch zu nichts. Jede MCU, die alle gestellten Aufgaben voll > erfüllt, ist automatisch auch die passende. > Ich hatte anfangs auch gerne mal Microoptimierung betrieben, also zuviel > Zeit für Sachen aufgewendet, die keine Meilensteine erbrachten. > Daß die neuen Features ganz nett sind, gebe ich doch gerne zu. Aber man > muß doch andere nicht dazu zwingen oder gar beleidigen. Volle Zustimmung.
Beitrag #7632201 wurde vom Autor gelöscht.
Peter D. schrieb: > Leute, die ständige Jagd nach der MCU mit den meisten Bells & Whistless > führt doch zu nichts. Jede MCU, die alle gestellten Aufgaben voll > erfüllt, ist automatisch auch die passende. Definitiv spätestens nicht mehr dann, wenn es sie garnicht mehr gibt... Aber oft auch schon lange vorher, wenn sie einfach nur unverschämt teuer wird. So funktioniert das nämlich heute oft. Die Teile, die die Hersteller eigentlich lieber nicht mehr liefern würden, werden nicht abgekündigt. Sie werden nur künstlich verknappt und damit teurer gemacht. Die explizite Abkündigung erfolgt erst, wenn der Hersteller relativ sicher ist, dass der Aufschrei der dann noch Betroffenen im Rauschen untergeht. Im Prinzip ist das Konzept der "stillen Abkündigung" aber schon seit langem Usus. Aber dank der "Chip-Krise" trat es zeitweise doch überdeutlich zu Tage. So deutlich, dass es eigentlich auch der letzte Nixmerker mitbekommen haben sollte...
Ob S. schrieb: > Die explizite Abkündigung ist inzwischen erfolgt für AT89xxxx, ATMEGA16x, ATMEGA32x, ATMEGA48x, ATMEGA644x, ATMEGA85x5L, ATMEGA88, ATMEGA8A, ATTINY13V, ATTINY24, ATTINY44, ATTINY461, ATTINY48, ATTINY84, ATTINY861 and ATTINY88 device families in PDIP.
Gerhard H. schrieb: > Ob S. schrieb: >> Die explizite Abkündigung > > ist inzwischen erfolgt für > > AT89xxxx, ATMEGA16x, ATMEGA32x, ATMEGA48x, ATMEGA644x, ATMEGA85x5L, > ATMEGA88, ATMEGA8A, ATTINY13V, ATTINY24, ATTINY44, ATTINY461, ATTINY48, > ATTINY84, ATTINY861 and ATTINY88 device families in PDIP. Viel interessanter wäre eine Liste der "stillen Abkündigungen". Denn die zu recherchieren, macht viel mehr Aufwand. Zum Glück gibt es für sowas die Einkaufs-Leute. Da muss man sich nicht selber mit beschäftigen. Und dafür, den Kunden ein Redesign schmackhaft zu machen, ist wiederum der Vertrieb zuständig. Geht mich auch nix an. Ich muß bloß sagen, wodurch wir die MCU im konkreten Design kostentechnisch am Besten ersetzen könnten. Das ist meistens relativ einfach, kann aber in speziellen Fällen auch mal recht kompliziert werden.
Hallo, wurde die Recherche Halbherzig durchgeführt? Stichprobenartig geprüft. Es gibt zumindestens mittels "A" einen Ersatz. Beim ATmega328P ist schon lange klar das es einen 328PB Nachfolger gibt. Echte Ersatzlose Abkündigung kann ich nicht erkennen. AT89xxxx ...... ATMEGA16x ..... ATMEGA32x ..... ATMEGA328PB ATMEGA48x ..... ATMEGA644x .... ATMEGA85x5L ... ATMEGA88 ...... ATMEGA8A ...... ATTINY13V ..... ATTINY24 ...... ATTINY44 ...... ATTINY461 ..... Newer Device Available ATTINY461A ATTINY48 ...... in Production ATTINY84 ...... Newer Device Available ATTINY84A ATTINY861 ..... Newer Device Available ATTINY861A ATTINY88 ...... in Production Außerdem, selbst wenn einmal eine ganze Reihe verschwindet muss man sich damit abfinden und mit dem Nachfolgemodellen leben. Ihr müsst euch doch auch einmal in die Lage der Hersteller reinversetzen. Die können nicht ohne Ende und bis auf alle Ewigkeit uralte Modelle parallel zu allen Neuen Modellen herstellen. Wer soll denn die Kapazitäten vorhalten? Die hornalten Modelle blockieren Kapazitäten für alles andere. Wir sehen doch jetzt schon den Wahnsinn des Kapazitätsausbaus. Dass kann niemals so weitergehen, bei keinem Hersteller. Ich wette, wenn sie für euch die hier rumheulen alle Modelle vorhalten würden, dann würdet ihr über die Preise rumheulen. Bis zu einem gewissen Punkt müssen die Hersteller auch rentabel arbeiten. Sonst gibts gar keine Produkte mehr. Das wollt ihr schließlich auch nicht. Außerdem kann immer noch rechtzeitig Bedarf angemeldet werden und die eigenen Lager gefüllt werden. Am Bsp. vom berühmten Atmega328P erfolgt der Übergang schon seit Jahren hin zum Atmega328PB. Wer da rumheult dem kann man nicht helfen. Beim Thema Leistungsschalter ist das noch krasser. Hierbei geht es in erster Linie um Effizienz, Effizienz, Effizienz. Da kann mir niemand erzählen das er nach 50 Jahren immer noch seine dann hornalten Geräte verkaufen möchte geschweige denn verkauft bekommt. E-Auto. Die Ladeverluste müssen reduziert werden. Die Ladespannung wird standig erhöht werden. Ladesäulen. Die Ladeverluste müssen reduziert. Der gesamte Ladevorgang muss schneller werden. Das funktioniert nicht mit 50 Jahre alter Halbleitertechnik. Niemand kann mir erzählen das er in 10 Jahren noch mit 22kW in der Pampa stehen möchte und wartet bis die Batterie endlich voll ist. Schon allein aus dem Grund müssen die Produktentwickler sich sowieso immer mit neuen Produkten befassen und diese in verkaufbare Produkte "gießen". Oder Autozyklus. Wieviel Jahre lang lief ein Golf 2 vom Band? Wieviel Jahre lief der Golf 7 vom Band? Auch die Produktzyklen werden immer kürzer. Jahrzehnte gab es Radio DIN Schächte. Das ist schon lange vorbei. Jetzt gibt es mit jedem Facelift Upgrades der verbauten Unterhaltungselektronik und Amaturenanzeigen usw. Es ist normal das immer neue Dinge verbaut werden. Was will man da noch mit alten Mist. Bin ich hier wirklich im Rentner Forum gelandet oder gibts auch junge bzw. jung gebliebene Entwickler die alles mehr positiv sehen und alles neue aufsaugen? Was ich noch loswerden möchte ist. Die Halbleiterhersteller stellen auch viele Produkte her die der Markt einfach verlangt oder die ein Kunde genauso haben möchte. Der Witz daran ist, die Entwickler die rumheulen sind genau ein Teil davon. Also was wollt ihr? Die einzigste Gruppe die nehmen muss was es gibt sind die "Bastler". Und mal ehrlich, um beim ATmega328P zu bleiben. Die Code Anpassungen für den PB sind minimalst. Bleibt das Programm unverändert kann es binär sogar ohne jede Veränderung auf den PB geflasht werden. Da steckt soviel Hirnschmalz drin und dennoch regen sich die Leute auf. Ab einem gewissen Punkt kann ich das nicht mehr nachvollziehen. Ganz ehrlich. Frohe Ostern.
:
Bearbeitet durch User
Veit D. schrieb: > Bis zu einem gewissen Punkt müssen die Hersteller auch rentabel arbeiten Endlich hat hier mal jemand Verständnis für die Hersteller. Microchip bemüht sich doch. Die neue AVR Reihe ersetzt locker alles alte (Ausnahme CAN). Noch dazu in allen denkbaren Gehäuseformen.
> wurde die Recherche Halbherzig durchgeführt?
...
Yes! Bwana!
Frohe Ostern allen!
Gerhard
:
Bearbeitet durch User
Veit D. schrieb: > wurde die Recherche Halbherzig durchgeführt? PCN# NTDO-11HXFX286 vom 14.7.23 https://www.microchip.com/product-change-notifications/#/ https://www.microchip.com/en-us/support/product-change-notification
:
Bearbeitet durch User
Hallo, https://www.microchip.com/product-change-notifications/#/ Okay, alles klar. Ich nehme den Teil zurück. ;-)
Gut, dass ich mir einen üppigen Vorrat an ATmega644 Modulen im DIL Format (ähnlich Arduino Nano) besorgt habe, als die Dinger billig waren.
Steve van de Grens schrieb: > üppigen Vorrat Das Zauberwort gegen Lieferengpässe, Teuerungen und Abkündigungen aller Art :)
:
Bearbeitet durch User
Steve van de Grens schrieb: > Gut, dass ich mir einen üppigen Vorrat an ATmega644 Modulen im DIL > Format Gerade im privaten Bereich juckt das doch so gut wie gar nicht. Und wenn ich einen uc, den es nicht in DIL gibt, unbedingt in DIL haben möchte, dann nehme ich ein Adapterplatinchen. Und den Herstellern wird der private Bereich auch nicht jucken. Klar, wenn man noch einen Sack voll gewünschter Teile liegen hat, ist das kein Nachteil.
:
Bearbeitet durch User
900ss schrieb: > Und den Herstellern wird der private Bereich auch nicht jucken. Das wiederum glaube ich nicht so ganz. Nicht nur, daß der Private der gleiche Mensch ist der u.U. genauso geschäftliche Entscheidungen fällt. Vor allem aber, weil die neue AVR Reihe komplett in DIL daherkommt. Das dürfte doch zuallererst die Bastler adressieren!
:
Bearbeitet durch User
900ss schrieb: > Und wenn ich einen uc, den es nicht in DIL gibt, unbedingt in DIL haben > möchte Es geht mir nicht direkt um das Dil Format, sondern dass es auf Lochraster und Steckbrett passt. > dann nehme ich ein Adapterplatinchen. Auch gut. Die genannten Module haben allerdings den USB Anschluss, die Stiftleiste für den Debugger, Quarz, Reset Taster, eine programmierbare LED und eine RS485 mit drauf. Das macht sie zum Prototyping attraktiver als nackte Adapterplatinen. Als Hobbybastler baut man fast immer nur Prototypen.
Steve van de Grens schrieb: > Als Hobbybastler baut man fast immer nur Prototypen. Oft. Aber längst nicht immer. Vor allem wenn es möglichst klein werden soll.
Gerhard H. schrieb: > Vor allem wenn es möglichst klein werden soll. Das gibt es bei mir nicht. Erst kommt die Funktion, dann je nach Fall entfeder die Stabilität/Robustheit oder die Kosten-Optimierung. Und erst danach schaue ich, wie klein das geht, falls die Größe überhaupt von Interesse ist. "Möglichst klein" überlasse ich den Smartphone-Herstellern. Wobei ... kleiner als 6 Zoll will ich auch das nicht haben.
Nun ja, die Größe wird öfter dann entscheidend wenn man etwas in ein gegebenes Gehäuse einbauen bzw. dort ergänzen muss. Mit den schön prototypigen Curiosity Nanos etwa, die ich hier bei jeder Gelegenheit nur empfehlen kann, käm man da nicht weit. Oft ist überhaupt der Platz begrenzt. So miniturisiert wie beim Smartphone muss es deshalb auch nicht werden. Dafür sorgt schon meine Vorliebe für THT Bauteile.
:
Bearbeitet durch User
Steve van de Grens schrieb: > Die genannten Module haben allerdings den USB Anschluss, die Stiftleiste > für den Debugger, Quarz, Reset Taster, eine programmierbare LED und eine > RS485 mit drauf. Da kannst du dann doch dieses Adapterplatinchen in den DIL Sockel stecken. Manchmal muss man evtl. einen Kompromiss machen will dann doch ein Signal fehlt. Aber evtl. kann man das dann verschmerzen. Ein fertig gekaufter Adapter wird wohl nicht gehen daher den kann man sich ja bauen wenn es wirklich wichtig ist. Steve van de Grens schrieb: > Es geht mir nicht direkt um das Dil Format, sondern dass es auf > Lochraster und Steckbrett passt. Gerade dort geht das dann genauso gut mit dem gekauften Adapter. Klar, es ist einfacher wenn man dann die DIL noch liegen hat, keine Frage. Finde es aber tatsächlich nicht dramatisch.
Steve van de Grens schrieb: > "Möglichst klein" überlasse ich den Smartphone-Herstellern. Wobei ... > kleiner als 6 Zoll will ich auch das nicht haben. Ich fand die 4.x" Geräte am besten. Das war handlich und passte in jede Tasche. Der Bildschirm reicht für alles "wichtige" unterwegs. Diese Frühstücksbretter die es heute gibt, finde ich lästig, sie sind eigentlich überwiegend im Weg.
Gerhard H. schrieb: > Nicht nur, daß der Private der gleiche Mensch ist der u.U. genauso > geschäftliche Entscheidungen fällt. Gerade im Geschäft wird DIL keine so große Rolle mehr spielen.
900ss schrieb: > Gerade im Geschäft wird DIL keine so große Rolle mehr spielen. Absolut. Industrielle Fertigung braucht DIL nicht. Dafür mancher Bastler um so mehr. So ein kleines wechselbares System ist da konkurrenzlos. Hände werden nicht kleiner, Augen nicht schärfer.
:
Bearbeitet durch User
Ob S. schrieb: > So funktioniert das nämlich heute oft. Die Teile, die die Hersteller > eigentlich lieber nicht mehr liefern würden, werden nicht abgekündigt. > Sie werden nur künstlich verknappt und damit teurer gemacht. Die > explizite Abkündigung erfolgt erst, wenn der Hersteller relativ sicher > ist, dass der Aufschrei der dann noch Betroffenen im Rauschen untergeht. Ja, das ist die kundenfreundlichste Lösung, den Übergang zu besseren Lösungen zu bewerkstelligen. Die alten Teile werden weniger geordert und damit wird ihre Herstellung automatisch teurer. Wer so eteas "künstlich" nennt, zeigt nur, daß er vom Prouktionsprozeß 0 (in Worten: Null) Ahnung hat. Natürlich gibt es Manager, die diese Automatik mit Genuß ausnutzen. Das liegt an unser aller Gier, möglichst viel für möglichst wenig Gegenleistung zu erhalten. Das Gegenstück dazu sind dann die unerfreulichen Kunden, die ein vormals günstig produziertes Teil trotz geänderten Rahmenbedingungen weiterhin billig haben möchten und den erhöhten Preis "unverschämt" nennen. Just my 2 cents
Gerhard H. schrieb: > 900ss schrieb: >> Gerade im Geschäft wird DIL keine so große Rolle mehr spielen. > > Absolut. Industrielle Fertigung braucht DIL nicht. Dafür mancher Bastler > um so mehr. So ein kleines wechselbares System ist da konkurrenzlos. > Hände werden nicht kleiner, Augen nicht schärfer. Moin, Aus dem Grund hat es Sinn auf vorgefertigte DIL MCU Einheiten wie Curisosity oder Nucleo Bords, oder auch die umstrittenen Arduino DIL Bords bzw vergleichbare sonstig erhältlichen Bords anderer Hersteller oder eigener Konstruktion zurückzugreifen. In Berücksichtigung dieser Randbedingung oder Vorzüge einer modularen Bauweise, macht da SMD dort nichts mehr aus und man erhielt als Bonus Austauschbarkeit. Viele unserer "Bastler" Projekte lassen sich dann auf einseitige LP oder Lochraster durchziehen. So wie hier auf Lochraster: Beitrag "Re: THT im Hobbybereich, hat das noch Zukunft?" Man sieht ja hier in manchen Beispielen wie beliebt diese Vorgehensweise ist. Da ist der Verlust von DIL MCUs nicht unbedingt soooooo schlimm. Für die kleinen Projektchen ist der Nano oder Pro-Mini schon meine bevorzugte Plattform. Auch die Nucleos sind da recht praktisch. Was MSP430 betrifft sind für mich auch die Launchpads von großem Interesse, weil man da auch mit dem Debugger arbeiten kann, was bei den AVR Arduinos nicht möglich ist. https://www.mikrocontroller.net/attachment/610877/IMG_9787.jpeg In Anbetracht aller Alternativen finde ich die Situation nicht zu schlimm. Ansonsten ist der DIL ATMEGA1284P ein gutes Arbeitspferd und mein bevorzugter AVR-Käfer. Der Trend von 5V auf niedrigere Betriebsspannungen ist natürlich manchmal eine P.I.A. wenn es darum geht 5V Peripherien zu verbinden. Da muß man aufpassen. Mir tun nur meine PICs leid, mit denen ich früher so gerne arbeitete. Für deren größeren Bauformen wie z.B. 18F8722 gab es ja nur SMD Bauformen. Die 30 und 33er hatten sich auch gut bewährt und machte in der Arbeit viel mit denen. Da war der 18F4620/2620 mein Liebling. Früher der 16F877A/876A. Ich sehe die Situation mit der Bauteilewahl nicht unbedingt so schlecht. Es gibt halt "Rough corners". Da muß man eben flexibel sein und den internationalen Marktplatz ausnützen. Als Hobbyist gelten Industriegesichtspunkte nicht und man kann mit Restbeständen noch nette Sachen nach Wahl konstruieren. Mein Trend ging dahin, so viel wie möglich, existierende Zusatzmodule auszunützen, die mittlerweile so vielfaltig erhältlich sind. Wünsche Euch frohe Ostern und hält den Lötkolben warm... Gruß, Gerhard
:
Bearbeitet durch User
Gerhard O. schrieb: > Da ist der Verlust von DIL MCUs nicht unbedingt soooooo schlimm. Der Verlust von DIL ICs generell relativiert sich nicht nur dadurch, daß der SMD Ersatz heute vielfach vormontiert auf Modulen daherkommt sondern auch mit dem Wandern vieler Funktionalitäten in die Software von Mikrocontrollern. Diese wiederum bleiben in ihren typischen 8Bit Bastler-Inkarnationen ja weiter als DIL erhältlich (siehe AVR-Dx/Ex), leistungsfähigere MCUs stehen mit ihrer oft komplizierteren Bauweise und Beschaltung aber schon weit weniger im Fokus, als daß man damit als Bastler noch von grundauf Hardware konstruierte. Bei den vielen Varianten von fertigen ESP32 bis PiPico Modulen steht im Grunde nur noch die Software im Mittelpunkt. Den RP2040 Controller etwa wird kein Bastler mehr einzeln kaufen. > Mir tun nur meine PICs leid, mit denen ich früher so gerne arbeitete. Mein allererster PIC war gleich dermaßen umständlich programmierbar, daß der Schwenk zum AVR wie eine Erlösung war. Das dürfte sich heute anders darstellen und selbstredend gibt es in den beiden 8 bittigen Universen dermaßen viele Überschneidungen und man gespannt sein darf, wie lange es bei Microchip wirtschaftlich noch vertretbar ist diese Welten getrennt und gleichermaßen zu halten. Glücklicherweise ersetzen eine Handvoll neuer AVRs hunderte alter Varianten- ein maßvolles "Aufräumen" hätte damit erstmal genug Einsparpotential.
:
Bearbeitet durch User
Gerhard H. schrieb: > wie lange es bei Microchip wirtschaftlich noch vertretbar ist diese > Welten getrennt und gleichermaßen zu halten. Schau mal, welche avr-gcc Version in Microchips kommerziellem XC8 Paket enthalten ist. Mir sagt das vorgefundene, dass ich keine Lebenszeit mehr in dem Erlernen neuer AVR Serien stecke. Bei mir ist mit ISP+Debugwire das Ende dieser Fahnenstange erreicht. Die nächste Stange trägt die Flagge von ST.
:
Bearbeitet durch User
Steve van de Grens schrieb: > dass ich keine Lebenszeit mehr in dem > Erlernen neuer AVR Serien stecke Da stellt sich meine Hobby-Situation aber ganz anders dar: In meiner Lebenszeit werde ich vermutlich keinen komplexeren Controller für Selbstbauten mehr benötigen. Die 8Bitter liefern (mir) mehr als genug Leistung, DIL, 5 Volt, Robustheit und viel simplere Programmierbarkeit. Neue AVR-Serien "bieten" zudem weit weniger Lernstoff als ARM und Konsorten. Insofern kosten sie auch viel weniger Lebens/Umlernzeit. Das ist natürlich keine allgemeingültige Aussage zu Sinn und Zweck eines solchen Umstiegs- und ist bei jedem (Bastler) je nach Ausbildung, Anwendungen und Programmierformen anders. > Bei mir ist mit ISP+Debugwire das Ende > dieser Fahnenstange erreicht. Absolut schade. Denn auf diesem Gebiet ging mit UPDI richtig was weiter.
:
Bearbeitet durch User
Falls sonst noch jemand jemand den Wechsel von AVR/PIC nach STM erwägt: Ich empfinde die STM32L0 Serie für den Anfang als angenehm. Ihre Komplexität ist nur wenig über den alten AVR (die aktuellen kenne ich nicht). Sie sind ab 1 Euro zu haben, und ein passender Debugger (für alle STM32) kostet 3 Euro.
:
Bearbeitet durch User
Steve van de Grens schrieb: > Ich empfinde die STM32L0 Serie für den Anfang als angenehm. Um das mal richtig einzuordnen: Steve van de Grens schrieb: > Ich habe Assembler in den 90er Jahren gelernt und seit dem auf > unterschiedlichen Architekturen verwendet. Für AVR habe ich ein ASM > Tutorial geschrieben, das mehrere Schulen im Unterricht verwendet haben. > Beruflich arbeite ich an einem Softwarprojekt, in das unser GF bisher > mehr als 6 Millionen Euro investiert hat (nicht Mikrocontroller). Ich > bin dort einer von zwei Chef-Entwicklern. > Also erzähle du mir nicht, ich sei inkompetent. :)
Gerhard H. schrieb: > Denn auf diesem Gebiet ging mit UPDI richtig was weiter. Habe ich gesehen. Mir reicht es allerdings, auf einer Hochzeit zu tanzen, und ich bin schon auf der anderen. Es ist schließlich nur ein Hobby und ich habe noch Familie.
:
Bearbeitet durch User
Steve van de Grens schrieb: > Mir reicht es allerdings, auf einer Hochzeit zu tanzen. Das ist in der Tat am sinnvollsten. ARM bietet ein wesentlich breiteres Leistungsspektrum. Wenn, ja wenn man es denn wirklich braucht.
Wenn der Debugger bei Atmel nicht so schweineteuer gewesen wäre, und Arduino konsequent bei AVR geblieben wäre, dann hätte ich mir wahrscheinlich nie angeschaut, was die Konkurrenz so zu bieten hat. Die UPDI Modelle kamen dazu einfach zu spät. Dieser Zug ist für mich abgefahren, ich bin anders abgebogen.
:
Bearbeitet durch User
Steve van de Grens schrieb: > Wenn der Debugger bei Atmel nicht so schweineteuer gewesen wäre Mit EDBG ist ein Debugger heute schon bei diversen Microchip Prototyp-Boards sehr günstig dabei (und lässt sich auch alleine nutzen). > Arduino konsequent bei AVR geblieben wäre Warum das denn? Arduino verschleudert dermaßen Ressourcen daß man jede stärkere Hardware bitternötig hat.
Gerhard H. schrieb: > Mit EDBG ist ein Debugger heute schon bei diversen Microchip > Prototyp-Boards sehr günstig dabei Ja ich weiß, heute gibt es günstige Debugger. Damals nicht. >> wenn Arduino konsequent bei AVR geblieben wäre > Warum das denn? Mein erstes Modul mit einem ARM Controller war ein verdammt leistungsstarkes Arduino Board. Es wurde im Unterricht in einem Ferien-Kurs verwendet, den ich tatkräftig unterstützte. Aber es war teuer, deswegen habe ich nach Alternativen gesucht und fand so das BluePill Board mit STM32 für nur 1,50 Euro. Hätte Arduino keine ARM Boards im Programm gehabt, wäre ich wohl nie auf STM32 gekommen, denn nach wie vor sind mir die 8 Bit Controller leistungsstark genug. Was die Programmierung angeht, bevorzuge ich weiterhin bare-metal. > Arduino verschleudert dermaßen Ressourcen eben deswegen. Für den Einstieg ist es allerdings nett, hat durchaus seine Existenzberechtigung.
:
Bearbeitet durch User
Steve van de Grens schrieb: > Was die Programmierung angeht, bevorzuge ich > weiterhin bare-metal. ... was natürlich umso einfacher bleibt wie auch die Hardware einfacher gestrickt ist. Insofern interessieren mich 1,50€ für ein ST BluePill Board eigentlich herzlich wenig. Da gebe ich lieber das Doppelte aus um Wissen und vorhandenen Code weiter nutzen zu können, > denn nach wie vor sind mir die 8 Bit Controller > leistungsstark genug Das werden sie gewiss auch bleiben. So wie die vielen Steuerungsanwendungen bleiben die damit problemlos möglich sind. Steve van de Grens schrieb: > Für den Einstieg ist [Arduino] allerdings nett, hat durchaus > seine Existenzberechtigung Auf jeden Fall. Für mich hat alles Existenzberechtigung was Programmierung vereinfacht. Dazu dürfte dann zukünftig vor allem Codegenerierung durch KI gehören. Die zugrundeliegende Hardware selber belanglos werden.
Veit D. schrieb: > Beim ATmega328P ist schon lange klar das es einen 328PB Nachfolger gibt. So kann man nicht sagen. Das sind zwei völlig unterschiedliche Mikrocontroller. Vermutlich liegt eine Verwechslung mit dem Namen vor, da 328PB auch bei Anpassung des Programms 328P nicht ersetzen kann. Nicht wie mit 644P und 644PA, oder 1284 und 1284P.
Maxim B. schrieb: > Veit D. schrieb: >> Beim ATmega328P ist schon lange klar das es einen 328PB Nachfolger gibt. > > So kann man nicht sagen. Das sind zwei völlig unterschiedliche > Mikrocontroller. Vermutlich liegt eine Verwechslung mit dem Namen vor, > da 328PB auch bei Anpassung des Programms 328P nicht ersetzen kann. > Nicht wie mit 644P und 644PA, oder 1284 und 1284P. Was bezweckst du mit solchen unsinnigen Antworten?
Veit D. schrieb: > Was bezweckst du mit solchen unsinnigen Antworten? Wenn unsinnig, dann versuche mal 328PB mit einem 20 MHz externen Quarz zu starten! Bei 644P/PA Tausch kein Problem.
:
Bearbeitet durch User
Beitrag #7636183 wurde vom Autor gelöscht.
Beitrag #7636184 wurde vom Autor gelöscht.
Der Knackpunkt ist, dass der ATmega328PB keinen Full-Swing
Quarz-Oszillator mehr hat, den man für 20 MHz bräuchte.
> zwei völlig unterschiedliche Mikrocontroller
Finde ich allerdings arg übertrieben.
:
Bearbeitet durch User
Steve van de Grens schrieb: > Der Knackpunkt ist, dass der ATmega328PB keinen Full-Swing > Quarz-Oszillator mehr hat, den man für 20 MHz bräuchte. Das macht Tausch 328P für 328PB in vielen Fällen unmöglich, deshalb darf PB nicht als Nachfolger (wie Veit D behauptet) und Ersatz für P betrachtet werden. Einfach noch ein Controller, der für etwas andere Aufgaben passt als P.
:
Bearbeitet durch User
Maxim B. schrieb: > Das macht Tausch 328P für 328PB in vielen Fällen unmöglich, Wirklich viele? Das hast du dir doch mur ausgedacht! Ich kenne keinen einzigen Fall, wo ein ATmega328 mit 20 MHz Quarz betrieben wird. Mit externen Taktgeber habe ich ihn allerding gesehen, da wäre der Nachfolger als Ersatz geeignet.
:
Bearbeitet durch User
Speed warning for 20 MHz version: The 20 MHz resonator frequency exceeds the maximum explicitly allowed in the ATmega328PB datasheet. In our basic testing, the 20 MHz resonator appears to function without problems, but for any critical applications you should confirm for yourself that this product is appropriate. https://www.pololu.com/product/3161
Georg M. schrieb: > Speed warning for 20 MHz version ... Erstaunlich, dass sie es trotzdem so verkaufen. Das wäre mir zu riskant.
Maxim B. schrieb: > Steve van de Grens schrieb: >> Der Knackpunkt ist, dass der ATmega328PB keinen Full-Swing >> Quarz-Oszillator mehr hat, den man für 20 MHz bräuchte. > > Das macht Tausch 328P für 328PB in vielen Fällen unmöglich, deshalb darf > PB nicht als Nachfolger (wie Veit D behauptet) und Ersatz für P > betrachtet werden. Einfach noch ein Controller, der für etwas andere > Aufgaben passt als P. Wenn die fehlende 20MHz Quarz Option dein einziges Problem ist, dann ist die Welt doch in Ordnung. Wurde damals schon in diversen Threads hoch und runter diskutiert. Quarzoszillatoren sollen laut Buschfunk auch schon verbreitet sein. Drop In Ersatz bleibt er deswegen dennoch, auch wenn ich mich wiederhole, weil Binärkompatibel. Deine Behauptung es wäre ein vollkommen anderer Controller ist allein deswegen schon Unsinn.
Veit D. schrieb: > Quarzoszillatoren sollen laut Buschfunk auch > schon verbreitet sein. Leider sind die meisten ziemlich stromhungrig. Ich habe bisher nur eine akzeptable Variante gefunden: SG5032CAN mit 3,3 Volt (1,8 mA max) und danach noch 74AHCT1G125 für 5 Volt. Aber auch so, mit Quarz ist Stromverbrauch kleiner als mit einem externen Oszillator. Zum Vergleich: SG5032CCN für 16 MHz verbraucht bis 20 mA (bei mir waren ca. 17 mA). 17 mA allein für Quarzoszillator!!! Ich habe bisher mit ATMega328P nur mit 16 MHz gearbeitet, so war für mich einfacher, mit einem Timer 1 ms-Puls zu bekommen, als mit 20 MHz. Jetzt habe ich mit AVR128DB begonnen, hier sind Beschränkungen solcher Art etwas milder.
:
Bearbeitet durch User
Maxim B. schrieb: > Leider sind die meisten ziemlich stromhungrig. Ein Grund mehr, auf Quarztaktversorgung generell zu verzichten und die intern taktstabileren neuen AVRs zu bevorzugen.
Bevor's vergessen geht, die Killer Anwendung, welche einen Umstieg von 8 bit auf 32 bit noetig macht sind graphische Displays, welche etwas mehr wie nur etwas Text anzeigen sollen. Ja, es gibt graphische Displays mit Libraries und eigener Intelligenz, die koennen dann aber grad das Gewuenschte nicht.
Purzel H. schrieb: > Killer Anwendung > graphische Displays Wenn eine lokale Steuerung ein großes Display benötigt. Und man mehr Geld für ein intelligentes Display nicht ausgeben mag. Ein solches hab ich mit einem uniTFT sehr zufriedenstellend am 8Bitter im Einsatz. Sparte auch sehr viel Entwicklungsarbeit. Ein wichtiger Trend weist aber weg vom lokalen Display. Anzeigen nämlich, die man aus Mobilitätsgründen besser gleich auf einer Webseite platziert. Gewiss, der Killer 32Bit (bessergesagt das Fertigmodul a'la Raspi und Konsorten) macht auch auf diesem Gebiet Furore. Selbst hier bieten sich aber Fertiglösungen an die man an sein 8Bit System anflanschen kann- um damit ganz bequem weiterwurschteln zu können :)
:
Bearbeitet durch User
Purzel H. schrieb: > Bevor's vergessen geht, die Killer Anwendung, welche einen Umstieg von 8 > bit auf 32 bit noetig macht sind graphische Displays, welche etwas mehr > wie nur etwas Text anzeigen sollen. Ja, es gibt graphische Displays mit > Libraries und eigener Intelligenz, die koennen dann aber grad das > Gewuenschte nicht. Ebenso TCP/IP.
Gerhard H. schrieb: > Ein Grund mehr, auf Quarztaktversorgung generell zu verzichten und die > intern taktstabileren neuen AVRs zu bevorzugen. Obwohl interne RC-Takterzeugung besser wurde, bleibt die Genauigkeit schlechter als bei Quarz. Wenn ein Gerät nicht nur im Zimmer arbeiten wird, sondern auch in anderen Räumen, ist Quarz nach wie vor wünschenswert. Außerdem verstehe ich nicht: warum sollte man 20 Cent-Teil einsparen, wenn dadurch die Arbeit viel sicherer wird? Gerhard H. schrieb: > Sparte auch sehr viel Entwicklungsarbeit. > Ein wichtiger Trend weist aber weg vom lokalen Display. Anzeigen > nämlich, die man aus Mobilitätsgründen besser gleich auf einer Webseite > platziert. Ich lebe wohl in einem anderen Deutschland: hier gibt es nicht einmal Strom in jeder Friedhofskapelle. Was für "Webseite"? Alle Geräte sollen autark bleiben. Was "Trend" heißt, ist mir eigentlich egal: ich lebe mein eigenes Leben. Letzte Jahre bewege ich mich genau in Gegenrichtung: alle meine Instrumente bekommen Möglichkeit, netzunabhängig (vor allem ohne Stromnetz) zu arbeiten. Hier ist das wichtig. Ja, Farbfotos mit AVR zu zeigen, wer das braucht, das geht kaum. Aber Text und Symbole kann auch AVR sehr gut darstellen. Wozu brauche ich Fotos beim Orgelspiel? Meine Viscount Cantorum Duo hat als Anzeige einfarbige Grafik 128x64, das reicht eigentlich. Und im 2016 gekaufte 2-manualige Viscount Vivace, womit ich zu Hause übe, hat alte Symbolanzeige, 4 Zeilen je 20 Buchstaben. Um Instrument einzustimmen, reicht das. Man könnte sagen, die Italiener seien zu konservativ? Aber was Orgelklang betrifft, ist Cantorum Duo so, daß von unten ich selbst kaum noch glauben kann, daß das eine Elektronik ist. Manche Akustik klingt weniger "natürlich" :) Offensichtlich erfüllen auch solche Anzeigen ihre Aufgabe perfekt.
:
Bearbeitet durch User
Maxim B. schrieb: > Obwohl interne RC-Takterzeugung besser wurde, bleibt die Genauigkeit > schlechter als bei Quarz Aber ist inzwischen gut genug für's meiste. Insbesondere für die UARTs. > Wenn ein Gerät nicht nur im Zimmer arbeiten wird, sondern auch in > anderen Räumen, ist Quarz nach wie vor wünschenswert. Ich habe einen 4808 ohne Quarz und mit UART-Übertragung im Außeneinsatz einer Wetterstation. > warum sollte man 20 Cent-Teil einsparen, wenn dadurch die Arbeit viel > sicherer wird? Wie man sieht wird damit die Arbeit eher unsicherer:' Beitrag "Müll in serieller Übertragung wenn Kondensator am Quarz berührt wird" Scheint ja mental für manchen recht schwer zu sein sich von Quarzen zu verabschieden... Vermutlich geben sie Dir aber das letzte bischen subjektive Sicherheit bei den zu erzeugenden Frequenzen !? :) > Letzte Jahre bewege ich mich genau in Gegenrichtung: alle meine > Instrumente Da brauchts keine Display-Verlagerung auf Webseiten. Volle Zustimmung. Im smarten Home, meinem Tummelplatz, schaut das schon ganz anders aus.
:
Bearbeitet durch User
Gerhard H. schrieb: > Wie man sieht wird damit die Arbeit eher unsicherer:' > > Beitrag "Müll in serieller Übertragung wenn Kondensator am Quarz berührt > wird" Dann sollte man Kondensator am Quarz nicht berühren, und alles wird sofort sicher? Gerhard H. schrieb: > Im smarten Home, meinem Tummelplatz, schaut das schon ganz anders aus. Ich habe letzte Jahre meine Instrumentensammlung ausgebaut: zu viel Kirchen und Kapellen, wo keine intakte Orgel steht, und kein Geld für Instandsetzung leider... Nun kann ich sagen, daß ich das Ziel erreicht habe: ich habe mehrere Varianten bis zu einer zweiman.Orgel mit Pedal, und alles kann notfalls von Akku laufen. Aber wie immer, Verbesserungen sind immer möglich und wünschenswert... Zweiman.Orgel mit Pedal ist natürlich schön, aber dann Aufbauzeit 40 Minuten, und ich kann diese Zeit kaum noch reduzieren. D.h. für reguläre GD ist das ungeeignet, nur für besondere Fälle. Ansonsten habe ich mehrere Varianten bis einschließlich "Beerdigungskeyboard", nur 3,5 kG (und Gewicht ist hier einzige Vorteil :) ).
:
Bearbeitet durch User
Schon mal von der Lebensweisheit "Keep it simple" gehört,Maxim? Was man für die Funktion einsparen kann sollte man einsparen. Jedes überflüssige Teil ist nur mindestens überflüssig, kann maximal aber unnötige Probleme machen. Davon abgesehen sparts Platz und Kosten.
Gerhard H. schrieb: > Schon mal von der Lebensweisheit "Keep it simple" gehört,Maxim? > Was man > für die Funktion einsparen kann sollte man einsparen. Jedes überflüssige > Teil ist nur mindestens überflüssig, kann maximal aber unnötige Probleme > machen. Davon abgesehen sparts Platz und Kosten. Ich studierte zwar in Sachsen, aber anglo-sächsisch kenne ich nicht so gut :) Ich löte Quarz ein und denke nicht mehr über Genauigkeit von Frequenzen. Die Möglichkeit, darüber nicht denken zu müssen ist für mich mehr als 20 Cent wert.
Moin, die Keramikresonatoren der üblichen Arduino Boards sind für genaue Zeitmessungen im us Bereich nicht sehr gut. Da kaufe ich mir, sofern erhaeltlich, lieber Pro-Mini Bords mit richtigen HC-49/S Footprint. Solche Bord-Oszillatoren schwingen um Groessenordnungen stabiler. Siehe hier: Pro-Mini mit 16MHz Quarz: Beitrag "Re: AVR T1 Capture Problem - Meinung erbeten" Nano mit Keramik Resonator Beitrag "Re: AVR T1 Capture Problem - Meinung erbeten" Beide Messungen unter gleichen Bedingungen durchgeführt. Für Meßanwendungen in der Zeit-Domain ist eine Quarz-Zeitbasis erwiesenermaßen besser, wenn es um us-Bereich Auflösung geht. Gerhard
Gerhard O. schrieb: > die Keramikresonatoren der üblichen Arduino Boards sind für genaue > Zeitmessungen im us Bereich nicht sehr gut. Interessant daß die immer noch Verwendung finden. Verglichen habe ich mit dem internen Takt neuerer AVRs. Wären für (noch) genaue(re) Zeitmessungen in absoluten Zeiteinheiten nicht 32Bitter besser? Arduino scheint mir für solche Zeitmessungen ohnehin nicht ideal. Maxim B. schrieb: > Die Möglichkeit, darüber nicht denken zu müssen ist für mich mehr als 20 > Cent wert. Na vielleicht bleibt die quarzlose Möglichkeit ja jetzt wenigstens im Hinterkopf :)
Gerhard H. schrieb: > Na vielleicht bleibt die quarzlose Möglichkeit ja jetzt wenigstens im > Hinterkopf :) Sie bleibt für Anwendungen, wo genaue Frequent weniger wichtig ist. Als Beispiel: separate AVR-Mikrocontroller, der Bildschirm mit ILI9488 bedient. SPI-Operationen Punkt zu Punkt brauchen viel Zeit, deshalb kann es vernünftig sein, dafür extra Hilfscontroller vorzusehen, der Befehle von Hauptcontroller über USART synchron bekommt: eine Linie von Punkt x bis Punkt y zeichnen, ein Symbol Größe x in Position y mit Farbe z zeichnen usw. Hier wird USART über den Takt von Hauptcontroller synchronisiert, deshalb ist eigene Quarz nicht notwendig. Gerhard O. schrieb: > die Keramikresonatoren der üblichen Arduino Boards sind für genaue > Zeitmessungen im us Bereich nicht sehr gut. Auch gewöhnliche Quarze mit 30 oder 50 ppm sind für genaue Zeitmessungen zu grob. Besser dafür die Quarzoszillatoren mit z.B. 0,5 ppm nehmen wie TG2520SMN. Auch nicht so wahnsinnig teuer, auch Stromverbrauch unter 2 mA. Die geben zwar kein Takt für digitale Anwendung sondern beschränkten Sinus, deshalb ist danach noch ein Inverter ohne Puffer notwendig, so wie 74LVC1GU04.
:
Bearbeitet durch User
Maxim B. schrieb: > Sie bleibt für Anwendungen, wo genaue Frequent weniger wichtig ist. Die interne Taktfrequenz neuerer AVRs langt für die meisten Anwendungen. Zeitmessungen in absoluten Mikrosekunden, abseits purer Zeitvergleiche, sind eine der wenigen Ausnahmen. Das Timing der Ansteuerung von Peripherien aller Art hat eigentlich immer einen ausreichenden Toleranzbereich. Eine andere Ausnahme sind vielleicht noch Echtzeituhren in Software.
:
Bearbeitet durch User
Angehängte Dateien:
-
AVR_OSCHF_Auto-Tune.png
66 KB
Auto-Tuning mit dem Uhrenquarz (Ultra Low Power RTC Oscillator) Auto-Tuning for Improved Internal Oscillator Accuracy The OSCHF output frequency can be calibrated by automatic tuning against an external 32.768 kHz crystal oscillator. (AVR_DB Datasheet)
Georg M. schrieb: > The OSCHF output frequency can be calibrated by automatic tuning against > an external 32.768 kHz crystal oscillator. Dann sparen wir zwei Pins für Quarz für 24 MHz und verlieren zwei andere Pins für Quarz 32768 Hz. Oder statt Pin für externe 24 MHz verwenden wir Pin für externe 32768 Hz. Wo ist Gewinn? Einzig mögliche Vorteil dann: wir können mit AVR128DB64 gleichzeitig SPI-0 und USART-0 verwenden, da USART-2 als UART von für 32768 Hz notwendigen PF0, PF1 auf PF4, PF5 umgeschaltet werden kann.
:
Bearbeitet durch User
Maxim B. schrieb: > verlieren zwei andere Pins für Quarz Ja stimmt Maxim. Daß man für überflüssige Quarze auch noch Pins verliert den Kontra-Punkt hatten wir noch gar nicht! > Einzig mögliche Vorteil dann Naja, Du hast den passenden Takt für eine Uhr + einen noch stabileren System-Takt. Wenns wirklich gebraucht würde.
:
Bearbeitet durch User
Maxim B. schrieb: > Veit D. schrieb: >> Beim ATmega328P ist schon lange klar das es einen 328PB Nachfolger gibt. > > So kann man nicht sagen. Das sind zwei völlig unterschiedliche > Mikrocontroller. Vermutlich liegt eine Verwechslung mit dem Namen vor, > da 328PB auch bei Anpassung des Programms 328P nicht ersetzen kann. > Nicht wie mit 644P und 644PA, oder 1284 und 1284P. Diese Aussage halte ich für übertrieben. Ich habe vor einiger Zeit ein PCB für 328P entworfen, dann aber ahnungslos 328PB bestellt. Dennoch konnte damit ich das PCB, mit Messer und Fädeldraht leicht modifiziert, in Betrieb nehmen. Ja, die Taktversorgung meines CAN-IC durch den XO-Ausgang hat nicht mehr funktioniert, und ich musste dafür dann den CLKOUT-Ausgang benutzen. Ansonsten waren aber keine Softwareanpassungen nötig, noch nicht einmal im Bootloader. LG, Sebastian
Gerhard H. schrieb: > Naja, Du hast den passenden Takt für eine Uhr + einen noch stabileren > System-Takt. "Noch stabileren" stimmt nicht. Interne RC-Taktquelle, auch nach 32768 Hz Quelle nachgestimmt, wird nicht so genau wie Quarz für 20 oder 24 MHz. Das ist ja kein PLL, sondern nur eine Nachstimmung, 32 Schritte nach unten und 31 Schritt nach oben in OSCHFTUNE-Register. Nur, wie gesagt, ist dann möglich, Port A (sonst für CPU-Takt benutzt) vollständig für SPI-0 und USART-0 benutzen. Für DB28 hat das nicht so viel Sinn, da wir dann für 32768 Hz USART-2 verlieren (aber wir tauschen asynchrone USART-2 für synchrone USART-0). Für DB32, DB48 und DB64 könnten wir aber damit einen seriellen Port wirklich gewinnen. Zwar ist dann USART-2 nur als UART nutzbar, d.h. nicht als z.B. zusätzliche SPI-Master.
:
Bearbeitet durch User
Maxim B. schrieb: > wird nicht so genau wie Quarz für 20 oder 24 MHz. Mag sein Maxim, das hab ich mangels Bedarf noch nicht genauer verglichen. Stabiler eingehalten wird der Takt mit diesem Autotuning trotzdem- das meint selbstverständlich in erster Linie Abhängigkeiten von der Temperatur und weniger Exemplar-Streuungen. Ab und zu messe ich einzelne intern erzeugte Frequenzen aus blanker Neugier mal am Oszilloskop aus. Da bin ich immer wieder beeindruckt, wie genau und serienmäßig die Vorgaben bei den neuesten AVRs eingehalten werden. Was an Peripherie durch überflüssig angeschlossene Quarze pinmäßig unmöglich wird war bei mir glücklicherweise noch kein Thema. Aber wie ich sehe, musstest Du Dir da schon ordentlich den Kopf zerbrechen. Dafür bleibt das unnachahmliche Gefühl, über den denkbar präzisesten Takt zu verfügen. Es sei Dir gegönnt!
:
Bearbeitet durch User
Gerhard H. schrieb: > Ab und zu messe ich einzelne intern erzeugte Frequenzen aus blanker > Neugier mal am Oszilloskop aus. Oszilloskop, auch mit 14 bit und umso mehr mit nur 8 bit, ist keineswegs ein sehr genaues Gerät. Es kann zwar Frequenzziffer geben, aber nur so "genau" wie eine Atombombe: plus minus Kilometer :) Gerhard H. schrieb: > Dafür > bleibt das unnachahmliche Gefühl, über den denkbar präzisesten Takt zu > verfügen. Als Klavierstimmer weiß ich, daß auch Differenz um 1 Cent sehr gut hörbar ist. 1 Cent bei a1 entspricht 0,25 Hz / 440 Hz = 0,057%. 50 ppm entspricht ca. 0,1 Cent. So erscheint gewöhnliche Genauigkeit von Quarz 30 oder 50 ppm für mich zwar ausreichend aber keineswegs überflüssig.
:
Bearbeitet durch User
Maxim B. schrieb: > Oszilloskop, auch mit 14 bit und umso mehr mit nur 8 bit, ist keineswegs > ein sehr genaues Gerät. Oh, um alte und neue AVRs in ihrer unterschiedlichen System-Takt Temperatur-Abhängigkeit zu unterscheiden dafür langt es aber sehr wohl. Und das langt. Gemessen wird ein heruntergeteilter Takt. > Als Klavierstimmer weiß ich, daß auch Differenz um 1 Cent sehr gut > hörbar ist. Bei solcherlei entscheidender "Sensorik" darfst Du wirklich nicht an falscher Stelle sparen. Zum Glück schreit nur eine geringprozentige Anzahl von AVR Apps dermaßen hörbar nach Quarzen.
:
Bearbeitet durch User
J. S. schrieb: > Hast du dir schon einen Schrein für die AVR gebaut Sind wie Japaner? Lieber eine Kirche. Und unbedingt mit einer guten Orgel! :)
Die Japaner (vor allem Yamaha) können sehr gut elektronische (und sogar akustische! ) Klaviere bauen. Aber eine gute japanische Orgel habe ich noch nie gesehen. Ich hatte früher viele Kontakte mit Orgelbau. In Japan (aber auch in Südkorea) haben alles die deutschen Orgelbauer gemacht.
:
Bearbeitet durch User
Maxim B. schrieb: > Lieber eine Kirche Wobei man ergänzen sollte daß die praktischen Wunderwerke namens Mikrocontroller sicherlich wesentlich anbetungswürdiger wären als manche Reliquie in Kirchen!
:
Bearbeitet durch User
Für mich ist Kirche ein Raum, wo eine Orgel steht. In diesem Sinn ist mein Musikzimmer auch eine Kirche :) Ansonsten, was Reliquien betrifft - Gott ist ein, und was unten gemacht wird, eher lutherisch oder eher katholisch, das ist für mich weniger wichtig als was oben gemacht wird, auf der Orgelempore. Mit Glaubensrichtungen habe ich nie ein Problem gehabt. Einmal habe ich sogar eine orthodoxe Beerdigung gespielt! Obwohl eigentlich bei Orthodoxen gar kein Musikinstrument in GD erlaubt ist... Was alles gibt es nur in dieser Welt... Heutzutage kommt elektronische Technik immer mehr in Gebrauch. Ein Pfarrer braucht Mikrofon. Ich als Organist ließ mir Kamera mit Bildschirm einrichten, da Spiegel wegen Raumbeleuchtung kaum nutzbar ist... Warum nicht, wenn das alles zu Ehre Gottes dient? Auch Mikrocontroller finden hier würdigen Platz.
:
Bearbeitet durch User
Orgelkonzerte sind was absolut Schönes. Jedwede Unpräzision dabei was absolut Störendes.
Gibt's eigentlich auch polnische Orgel-Bibliotheken für den AVR128DB28 µC? Vielleicht versteckt in einem japanischen Schrein?
:
Bearbeitet durch User
Georg M. schrieb: > Polnische Orgel (Święta Lipka) "Fahren sie doch mal nach Polen, ihre Orgel ist schon da".
Ach Polen... Ich war nicht so oft dort, und schon gar keine Zeit für die Kirchen... Polen hat mich immer überrascht: schöne und moderne Schnellstraßen, wenn man aber ein bißchen zur Seite fährt, dann alles so marode, noch schlechter sogar als die Straßen in Dresden! Deshalb fahre ich Polen immer durch, so schnell wie es nur geht... Leider kenne ich niemand, der in Polen Orgelbau macht. Ob das dort gar existiert? Ich kenne noch ein Buch von Josepf Goebel aus Danzig: "Theorie und Praxis des Orgelpfeifenklanges. Intonieren und Stimmen." Einer von sehr wenigen, der überhaupt etwas über Intonation von Zungen schreibt, recht seltenes Buch. Aber er arbeitete noch vor dem Krieg, wie Danzig noch deutsch war. Aus späteren Zeiten habe ich über polnischen Orgelbau nichts gehört.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.