Forum: Mikrocontroller und Digitale Elektronik Arduino Bibliotheken funktionieren nicht beim AVR128DB-Prozessor


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Sebastian H. (sebastian_h809)


Lesenswert?

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

von Daniel F. (df311)


Lesenswert?

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

von Gerhard H. (hauptmann)


Lesenswert?

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.

von Veit D. (devil-elec)


Lesenswert?

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.

von Georg M. (g_m)


Angehängte Dateien:

Lesenswert?

Sebastian H. schrieb:
> Prozessor AVR128DB28

AVR128DB28 ist kein Prozessor, sondern ein Controller.

von Peter D. (peda)


Lesenswert?

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.

von Steve van de Grens (roehrmond)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

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.

von Jack V. (jackv)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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.

von Aloysius P. (Firma: FBI) (a_pendergast)


Lesenswert?

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.

von Jack V. (jackv)


Lesenswert?

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
von Gerhard O. (gerhard_)


Lesenswert?

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

von Gerhard H. (hauptmann)


Lesenswert?

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
von Peter D. (peda)


Lesenswert?

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.

von Gerhard H. (hauptmann)


Lesenswert?

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
von Rolf (rolf22)


Lesenswert?

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.

von Gerhard O. (gerhard_)


Lesenswert?

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
von Aloysius P. (Firma: FBI) (a_pendergast)


Lesenswert?

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.

von Sebastian W. (wangnick)


Lesenswert?

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

von Björn W. (bwieck)


Lesenswert?

Aloysius P. schrieb:
> Braucht man eine ZCD so sind die AVR DA‘s ne gute Wahl.

Was ist eine ZCD?

von Veit D. (devil-elec)


Lesenswert?

Hallo,

ZCD ... Zero Cross Detection

von Veit D. (devil-elec)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

Veit D. schrieb:
> ZCD ... Zero Cross Detection

Was stört Dich denn am analog Komparator?

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

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.

von Gerhard H. (hauptmann)


Lesenswert?

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
von Peter D. (peda)


Lesenswert?

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.

von Gerhard H. (hauptmann)


Lesenswert?

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
von Ob S. (Firma: 1984now) (observer)


Lesenswert?

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.

von Gerhard H. (hauptmann)


Lesenswert?

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
von Peter D. (peda)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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.

von Veit D. (devil-elec)


Lesenswert?

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.  ;-)

von Gerhard H. (hauptmann)


Lesenswert?

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
von Gerhard O. (gerhard_)


Lesenswert?

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
von Ob S. (Firma: 1984now) (observer)


Lesenswert?

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...

von Hans (ths23)


Lesenswert?

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.

von Gerhard H. (hauptmann)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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.

von Gerhard H. (hauptmann)


Lesenswert?

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
von Peter D. (peda)


Lesenswert?

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
von Gerhard H. (hauptmann)


Lesenswert?

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
von Christoph M. (mchris)


Lesenswert?

>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

von Peter D. (peda)


Lesenswert?

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
von Gerhard H. (hauptmann)


Lesenswert?

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
von Maxim B. (max182)


Lesenswert?

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
von Peter D. (peda)


Lesenswert?

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).

von Gerhard H. (hauptmann)


Lesenswert?

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
von J. S. (jojos)


Lesenswert?

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.

von Gerhard H. (hauptmann)


Lesenswert?

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?

von Peter D. (peda)


Lesenswert?

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.

von Gerhard H. (hauptmann)


Lesenswert?

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
von Georg M. (g_m)


Lesenswert?


von Peter D. (peda)


Lesenswert?

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
von Gerhard H. (hauptmann)


Lesenswert?

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
von Gerhard O. (gerhard_)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

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
von Gerhard H. (hauptmann)


Lesenswert?

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.
von Veit D. (devil-elec)


Lesenswert?

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
von Veit D. (devil-elec)


Lesenswert?

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.

von Aloysius P. (Firma: FBI) (a_pendergast)


Lesenswert?

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.

von Gerhard H. (hauptmann)


Lesenswert?

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 :)

von Peter D. (peda)


Lesenswert?

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.

von Cyblord -. (cyblord)


Lesenswert?

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.

von Gerhard H. (hauptmann)


Lesenswert?

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
von Veit D. (devil-elec)


Lesenswert?

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.
von Ob S. (Firma: 1984now) (observer)


Lesenswert?

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...

von Gerhard H. (hauptmann)


Lesenswert?

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.

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

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.

von Veit D. (devil-elec)


Lesenswert?

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
von Gerhard H. (hauptmann)


Lesenswert?

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.

von Gerhard O. (gerhard_)


Lesenswert?

> wurde die Recherche Halbherzig durchgeführt?
...

Yes! Bwana!

Frohe Ostern allen!

Gerhard

: Bearbeitet durch User
von Gerhard H. (hauptmann)


Lesenswert?


: Bearbeitet durch User
von Veit D. (devil-elec)


Lesenswert?

Hallo,

https://www.microchip.com/product-change-notifications/#/

Okay, alles klar. Ich nehme den Teil zurück. ;-)

von Steve van de Grens (roehrmond)


Lesenswert?

Gut, dass ich mir einen üppigen Vorrat an ATmega644 Modulen im DIL 
Format (ähnlich Arduino Nano) besorgt habe, als die Dinger billig waren.

von Gerhard H. (hauptmann)


Lesenswert?

Steve van de Grens schrieb:
> üppigen Vorrat

Das Zauberwort gegen Lieferengpässe, Teuerungen und Abkündigungen aller 
Art :)

: Bearbeitet durch User
von 900ss (900ss)


Lesenswert?

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
von Gerhard H. (hauptmann)


Lesenswert?

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
von Steve van de Grens (roehrmond)


Lesenswert?

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.

von Gerhard H. (hauptmann)


Lesenswert?

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.

von Steve van de Grens (roehrmond)


Lesenswert?

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.

von Gerhard H. (hauptmann)


Lesenswert?

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
von 900ss (900ss)


Lesenswert?

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.

von 900ss (900ss)


Lesenswert?

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.

von 900ss (900ss)


Lesenswert?

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.

von Gerhard H. (hauptmann)


Lesenswert?

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
von Klaus S. (kseege)


Lesenswert?

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

von Gerhard O. (gerhard_)


Lesenswert?

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
von Gerhard H. (hauptmann)


Lesenswert?

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
von Steve van de Grens (roehrmond)


Lesenswert?

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
von Gerhard H. (hauptmann)


Lesenswert?

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
von Steve van de Grens (roehrmond)


Lesenswert?

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
von Gerhard H. (hauptmann)


Lesenswert?

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.

:)

von Steve van de Grens (roehrmond)


Lesenswert?

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
von Gerhard H. (hauptmann)


Lesenswert?

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.

von Steve van de Grens (roehrmond)


Lesenswert?

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
von Gerhard H. (hauptmann)


Lesenswert?

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.

von Steve van de Grens (roehrmond)


Lesenswert?

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
von Gerhard H. (hauptmann)


Lesenswert?

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.

von Maxim B. (max182)


Lesenswert?

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.

von Veit D. (devil-elec)


Lesenswert?

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?

von Maxim B. (max182)


Lesenswert?

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.
von Steve van de Grens (roehrmond)


Lesenswert?

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
von Maxim B. (max182)


Lesenswert?

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
von Steve van de Grens (roehrmond)


Lesenswert?

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
von Georg M. (g_m)


Lesenswert?

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

von Steve van de Grens (roehrmond)


Lesenswert?

Georg M. schrieb:
> Speed warning for 20 MHz version ...

Erstaunlich, dass sie es trotzdem so verkaufen. Das wäre mir zu riskant.

von Veit D. (devil-elec)


Lesenswert?

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.

von Maxim B. (max182)


Lesenswert?

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
von Gerhard H. (hauptmann)


Lesenswert?

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.

von Purzel H. (hacky)


Lesenswert?

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.

von Gerhard H. (hauptmann)


Lesenswert?

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
von Cyblord -. (cyblord)


Lesenswert?

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.

von Maxim B. (max182)


Lesenswert?

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
von Gerhard H. (hauptmann)


Lesenswert?

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
von Maxim B. (max182)


Lesenswert?

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
von Gerhard H. (hauptmann)


Lesenswert?

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.

von Maxim B. (max182)


Lesenswert?

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.

von Gerhard O. (gerhard_)


Lesenswert?

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

von Gerhard H. (hauptmann)


Lesenswert?

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 :)

von Maxim B. (max182)


Lesenswert?

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
von Gerhard H. (hauptmann)


Lesenswert?

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
von Georg M. (g_m)


Angehängte Dateien:

Lesenswert?

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)

von Maxim B. (max182)


Lesenswert?

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
von Gerhard H. (hauptmann)


Lesenswert?

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
von Sebastian W. (wangnick)


Lesenswert?

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

von Maxim B. (max182)


Lesenswert?

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
von Gerhard H. (hauptmann)


Lesenswert?

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
von Maxim B. (max182)


Lesenswert?

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
von Gerhard H. (hauptmann)


Lesenswert?

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
von J. S. (jojos)


Lesenswert?

Gerhard H. schrieb
…

Hast du dir schon einen Schrein für die AVR gebaut wo du die täglich 
anbetest?

von Maxim B. (max182)


Lesenswert?

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! :)

von Gerhard H. (hauptmann)


Lesenswert?

J. S. schrieb:
> täglich anbetest

Täglich anbeten wär mir zu unproduktiv :)

von Maxim B. (max182)


Lesenswert?

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
von Gerhard H. (hauptmann)


Lesenswert?

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
von Maxim B. (max182)


Lesenswert?

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
von Gerhard H. (hauptmann)


Lesenswert?

Orgelkonzerte sind was absolut Schönes. Jedwede Unpräzision dabei was 
absolut Störendes.

von Georg M. (g_m)


Lesenswert?

Polnische Orgel (Święta Lipka)

https://www.youtube.com/watch?v=bmWwRtU3QwA

von Norbert (der_norbert)


Lesenswert?

Gibt's eigentlich auch polnische Orgel-Bibliotheken für den AVR128DB28 
µC?
Vielleicht versteckt in einem japanischen Schrein?

: Bearbeitet durch User
von Cyblord -. (cyblord)


Lesenswert?

Georg M. schrieb:
> Polnische Orgel (Święta Lipka)

"Fahren sie doch mal nach Polen, ihre Orgel ist schon da".

von Maxim B. (max182)


Lesenswert?

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
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
Noch kein Account? Hier anmelden.