Ich möchte hier sogar mal eine gewagte Prognose abgeben: Sie werden alle wieder kleiner werden. Dafür sehe ich verschiedene Gründe. Einer der trivialsten ist sicher, dass auch der Sand weniger wird und nicht nach wächst. Ich glaube insgesamt IC's und auch µC werden immer spezialisierter, aber dafür vernetzbarer werden. Irgendwo sitzt sicher, nur noch in besonders komplexen Systemen, das "Mainbrain" als 32, 64-bitter oder sonst eine beliebige Größe. Jede Komponente hat ihren eigenen Controller oder spezial IC. Nehmen wir ein Auto. Die Lampe hat ihr "eigenes Leben" und bekommt nur ein Signal etwas zu tun, den Rest macht sie selber. Ganz bewusst habe ich dieses Beispiel gewählt, weil so Rohstoffe zu sparen sind, in Form von weniger Kabeln, weil die "Nachbauer" es schwerer haben werden kompatibel zu bleiben und weil so die Verteilung der Aufgaben leichter wird. Ich will das gar nicht bis zum Erbrechen ausführen, aber als Anriss der möglichen Wege ist das, so denke ich, ein gutes Beispiel. Wenn man jetzt mal so einen ATtiny10 sieht, was man damit schon alles machen kann ... Es wird meiner Meinung nach dahin gehen.
Angehängte Dateien:
-
M88.jpg
140 KB
An den neuen PB-Megas finden sich zwei geheimnisvolle "Kontakte"... Weiß jemand was, es mit diesem Gehäusedetail auf sich hat?
Hi
>Weiß jemand was, es mit diesem Gehäusedetail auf sich hat?
Wenn die in der gleichen Höhe wie die Pin aus dem Gehäuse herauskommen
dürfte es sich um die Reste des Leadframes handeln.
MfG Spess
spess53 schrieb: > Reste des Leadframes Ok, interessant. Ist mir so an Chips noch nie aufgefallen. Diese "Reste" fanden sich in einer Serie von 25 Chips ausnahmslos in gleicher Weise.
Wo sind denn die neuen ATtinys nun?
Hi >Diese "Reste" >fanden sich in einer Serie von 25 Chips ausnahmslos in gleicher Weise. Das Ganze sieht nach einem Versatz im Gehäusewerkzeug aus. Normalerweise sieht man die Stege des Chipträgers nicht da die bündig mit der Gehäusekante abgeschnitten werden. MfG Spess
bork schrieb: > Wo sind denn die neuen ATtinys nun? Nächste Gelegenheit im Juni? Computex in Taiwan. Zwischen Ankündigung und realem Produkt liegen bei Atmel bekanntlich Welten.
:
Bearbeitet durch User
Juhuuf schrieb im Beitrag #4139700: > von dem man keine Ahnung hat. Wer ist "man" und warum hat "man" zwar tiefgreifende Ahnung von AVR so daß er alle Bits beim Vormnamen kennt, nicht aber von ARM wo das alles unterm Strich auch kein bisschen anders funktioniert? > aber dass ist nur möglich weil automatisierte Software nein, ohne all das gehts auch. Alles nur ne Frage der Umgewöhnung, es ist alles etwas umfangreicher aber nicht irgendwie komplizierter oder grundlegend anders.
:
Bearbeitet durch User
Bernd K. schrieb: > Alles nur ne Frage der Umgewöhnung, es > ist alles etwas umfangreicher aber nicht irgendwie komplizierter oder > grundlegend anders. Märchenonkel
Moby AVR schrieb im Beitrag #4139963: > Bernd K. schrieb: >> Alles nur ne Frage der Umgewöhnung, es >> ist alles etwas umfangreicher aber nicht irgendwie komplizierter oder >> grundlegend anders. > > Märchenonkel Nein.
Mein Gott, findet schon wieder die letzte Schlacht um die Menscheit statt? Ist ja grauenhaft. Kaum ein Thread in dem es irgendwie um Microcontroller geht, kommt hier ohne Glaubenskrieg aus. Arm dran oder Arm ab, alles ist schwer, wenn man es nicht kann und alles ist leicht, wenn man es kann. Hauptsache ist doch, dass am Ende die Anwendung funktioniert und das ganz gleich welcher uC da werkelt.
:
Bearbeitet durch User
Juhuuf schrieb im Beitrag #4140003: > im Fehlerfall > die möglichen Fehlerquellen einfacher ausmachen. So schauts aus. Einer der großen Vorteile einer einfachen Architektur. So sie denn für die vorgesehene Anwendung ausreicht ist sie ganz klar vorzuziehen. Keep it simple!
F. Fo schrieb: > Glaubenskrieg Da irrst Du Dich. Der wär in einem Forum der Fakten und Tatsachen schnell zu Ende. Tatsächlich sind es nur ebendiese, die eine Diskussion sinnvoll machen und am Laufen halten. > Hauptsache ist doch, dass am Ende die > Anwendung funktioniert Das setzen wir mal als selbstverständliches Ziel voraus. Hauptsache ist vielmehr, welcher Gesamtaufwand dazu vonnöten ist!
> Hauptsache ist vielmehr, welcher Gesamtaufwand dazu vonnöten ist!
Der Gesamtaufwand hängt von sehr vielen Faktoren ab.
- Welche Performance benötigt das System
- Welche Architektur beherrsche ich schon?
- Welche Programmiersprache beherrsche ich schon?
- usw...
Jeder dieser Faktoren beeinflusst den Gesamtaufwand. Zum Beispiel kann
es durchaus sein, dass ein Design auf einem 8-Bit µC erheblich schwerer
zu implementieren ist als auf einem 32bit.
Ich habe diese Erfahrung gemacht, als ich in den Bereich vorgestoßen
bin, an dem ein 8-bit an seine Leistungsgrenzen stößt. Genau in jenem
Bereich steigt der Aufwand plötzlich sprunghaft an (Optimirungsaufwand).
Das kann sogar soweit gehen, dass man ein Genie sein muss um ein
gefordertes Design noch auf einem 8bit zum laufen zu bringen.
Dann bin ich auf 32 bit umgestiegen und auf einmal war alles ganz
einfach (weil ich nicht mehr optimieren musste). Das Projekt war damals
ein Quadrocopter.
Da ich mich dann schon in 32bit eingearbeitet hatte, wollte ich nicht
mehr auf 8bit umsteigen (die Hürde war ja genommen). Seitdem nutze ich
für alles nur noch 32bit. Es ist einfacher, wenn man nicht mehrere
Architekturen gleichzeitig beherrschen muss.
Das war mein persönlicher Weg. Je nach Ausprägung der Begleitumstände
sieht dieser für jeden Menschen anders aus.
Wutzi schrieb: > an seine Leistungsgrenzen stößt. Genau in jenem > Bereich steigt der Aufwand plötzlich sprunghaft an Absolut. Deshalb werde ich nicht müde zu betonen Moby AVR schrieb im Beitrag #4140013: > Vorteile einer einfachen Architektur. > So sie denn für die vorgesehene Anwendung ausreicht Nun sind das erstens immer noch Millionen Steuerungs-Anwendungen, in denen zweitens selbst die Leistung eines AVR oft kaum zu 10% gefordert ist (gewisse Programmierfähigkeiten einmal vorausgesetzt). > ich mich dann schon in 32bit eingearbeitet hatte zählt eben ganz klar zum Aufwand, den man sich ebenso klar sparen kann, wenn die erwähnten Grenzbereiche (technisch aber auch durch die eigene Programmiereffizienz abgesteckt) absehbar nicht erreicht werden. > Seitdem nutze ich > für alles nur noch 32bit. Es ist einfacher, wenn man nicht mehrere > Architekturen gleichzeitig beherrschen muss. Bestimmt. Es vereinfacht. Aber es schränkt zum Teil an anderen Fronten wieder ein, indem zum Beispiel der erweiterte Spannungsbereich bis 5V nicht mehr zur Verfügung steht, bastlerfreundliche DIL Gehäuse Mangelware sind, teurere Entwicklungstools nötig werden, sich die Fehlersuche aufwendiger gestaltet usw. Die große AVR-Typenpalette mag keine herausragenden Eigenschaften bieten, aber sie bietet ein gutes Gesamtpaket.
F. Fo schrieb: > Arm dran oder Arm ab, alles ist schwer, wenn man es nicht kann.. Besser ist:
1 | Arm ab oder arm dran, |
2 | alles ist schwer, wenn man es nicht kann. |
Der Reim der Woche. Sorry, das konnte ich mir nicht verkneifen.
Moby AVR schrieb im Beitrag #4140372: > Wutzi schrieb: >> an seine Leistungsgrenzen stößt. Genau in jenem >> Bereich steigt der Aufwand plötzlich sprunghaft an > > Absolut. Deshalb werde ich nicht müde zu betonen > > Moby AVR schrieb im Beitrag #4140013: >> Vorteile einer einfachen Architektur. >> So sie denn für die vorgesehene Anwendung ausreicht > > Nun sind das erstens immer noch Millionen Steuerungs-Anwendungen, in > denen zweitens selbst die Leistung eines AVR oft kaum zu 10% gefordert > ist (gewisse Programmierfähigkeiten einmal vorausgesetzt). > >> ich mich dann schon in 32bit eingearbeitet hatte > > zählt eben ganz klar zum Aufwand, den man sich ebenso klar sparen kann, > wenn die erwähnten Grenzbereiche (technisch aber auch durch die eigene > Programmiereffizienz abgesteckt) absehbar nicht erreicht werden. > >> Seitdem nutze ich >> für alles nur noch 32bit. Es ist einfacher, wenn man nicht mehrere >> Architekturen gleichzeitig beherrschen muss. > > Bestimmt. Es vereinfacht. Aber es schränkt zum Teil an anderen Fronten > wieder ein, indem zum Beispiel der erweiterte Spannungsbereich bis 5V > nicht mehr zur Verfügung steht, bastlerfreundliche DIL Gehäuse > Mangelware sind, teurere Entwicklungstools nötig werden, sich die > Fehlersuche aufwendiger gestaltet usw. Die große AVR-Typenpalette mag > keine herausragenden Eigenschaften bieten, aber sie bietet ein gutes > Gesamtpaket. Das sehe ich im Grunde genauso. Ich denke auch in der Industrie wird jede Entwicklungsabteilung nach sehr rationalen Gesichtspunkten eine Entscheidung treffen. --> Im Hobbybereich sehe ich aber noch einen gewissen Vorteil, wenn man sich trotz der größeren Hürden direkt in 32 bit einarbeitet (auch wenn man erstmal mit 8 bit auskäme): Man zahlt quasi doppelt, wenn man billig einkauft. Will heißen: Man arbeitet sich doppelt ein, wenn man sich in 8bit einarbeitet und später aber mal mehr Leistung braucht. Hätte man sich direkt in 32bit eingearbeitet, wäre der Aufwand der Einarbeitung in die einfachere Architektur entfallen. Das wäre jetzt so ein Argument, welches ich bringen würde wenn ich einem Einsteiger zu 32bit raten würde: Der Aufwand ist am Anfang größer, aber am Ende des Tages kleiner (vorausgesetzt der Hobbymensch will später mal was komplexeres bauen).
Wutzi schrieb: > Das wäre jetzt so ein Argument, welches ich bringen würde wenn ich einem > Einsteiger zu 32bit raten würde: Der Aufwand ist am Anfang größer, aber > am Ende des Tages kleiner (vorausgesetzt der Hobbymensch will später mal > was komplexeres bauen). Wenn denn der Einsteiger fähig, gewillt und massiv motiviert ist, die 32-bittige Hürde überhaupt zu nehmen und nicht und mit höherer Wahrscheinlichkeit frustriert vorher aufzugeben. Da fällt der 8-Bit Einstieg ungleich leichter- insbesondere wenn man weiß, daß bereits diese Technik sehr weit trägt und (wahrscheinlich) für die eigenen Bedürfnisse auslangt. Überhaupt bietet sie dem normalsterblichen Bastler mit begrenztem Zeitbudget noch die Chance, sein System vollständig zu verstehen, zu beherrschen und sich selbst demzufolge immer helfen zu können- nicht nur fremdes Knowhow zuweilen recht unverstanden zur Anwendung zu bringen und bei Problemen dann dumm dazustehen. Am Ende des Tages sollten die realen Bedürfnisse der Anwendung im Vordergrund stehen. So ein Quadrocopter-Projekt dürfte zum Beispiel ob der umfangreichen Berechnungen mit höherer Genauigkeit sicher 32-bittig besser aufgehoben sein.
Moby schrieb: > Wenn denn der Einsteiger fähig, gewillt und massiv motiviert ist, die > 32-bittige Hürde überhaupt zu nehmen und nicht und mit höherer > Wahrscheinlichkeit frustriert vorher aufzugeben. Da fällt der 8-Bit > Einstieg ungleich leichter- insbesondere wenn man weiß, daß bereits > diese Technik sehr weit trägt und (wahrscheinlich) für die eigenen > Bedürfnisse auslangt. Überhaupt bietet sie dem normalsterblichen Bastler > mit begrenztem Zeitbudget noch die Chance, sein System vollständig zu > verstehen, zu beherrschen und sich selbst demzufolge immer helfen zu > können- nicht nur fremdes Knowhow zuweilen recht unverstanden zur > Anwendung zu bringen und bei Problemen dann dumm dazustehen. Am Ende des > Tages sollten die realen Bedürfnisse der Anwendung im Vordergrund > stehen. > So ein Quadrocopter-Projekt dürfte zum Beispiel ob der umfangreichen > Berechnungen mit höherer Genauigkeit sicher 32-bittig besser aufgehoben > sein. Ja - ich denke bei 32bit kann man dann durchaus auch den Weg gehen den µC ausschließlich mit c und mit Bibliotheken die es schon gibt zu benutzen. Es gibt immer irgendwann den Punkt wo es einfach zu komplex wird und es sich lohnt Abstraktion einzuführen. Einen Cortex M4 komplett zu durchschauen ist sicher ganz schon happig. Aber man muss es nicht unbedingt...
Angehängte Dateien:
-
OSCCAL-PA.png
53 KB -
OSCCAL-PB.png
54 KB -
MX8B.png
17 KB
Neben den 4 zusätzlichen, vollwertigen IOs bietet der in TQFP32 erhältliche neue Mega-PB vor allem einen genaueren internen RC-Oszillator. Damit entledigen sich die meisten Anwendungen endlich der Notwendigkeit, von einem Quarz samt Kondensator-Gehilfen taktversorgt zu werden. Interessant ist das natürlich insbesondere für alle UART-Anwendungen. Zudem steigt die maximal mögliche Taktfrequenz. In den beiden angehängten Diagrammkopien aus den Datenblättern von Mega88 PA/PB ist die Abhängigkeit der aus dem OSCCAL-Registerwert resultierenden Taktfrequenz dargestellt. Wie man schnell sieht ist der Kurvenverlauf= Frequenzänderung beim PB nun sehr schön linear. Wesentlich interessanter aber: Die beiden unterschiedlich ansteigenden Bereiche (via OSCCAL/Bit7 ausgewählt) überlappen sich Richtung Wert-Mitte beim PB-Typ kaum noch. Das eröffnet natürlich wesentlich mehr Einstellmöglichkeiten, die im höheren Bereich sogleich in mehr Abstufungen hin zu höheren Frequenzen reinvestiert werden: Nun sind da plötzlich über 18 MHz drin (Vorgängertypen 12 MHz). Für die, nach wie vor, Default-Frequenz von 8 MHz (via Fuse noch durch 8 geteilt) wird nun eine geringere Toleranz von 3% (Vorgänger: 10%) angegeben. Das habe ich neugierigerweise gleich mal anhand von 5 Stichproben überprüft: 1) 8,04 MHz 2) 8,04 Mhz 3) 8,10 MHz 4) 8,01 MHz 5) 8,06 MHz Das schaut doch schon mal sehr gut aus und liegt weit innerhalb der 3%. Nummer 3) habe ich jetzt (siehe Anhang) an interessanten Stellen genauer vermessen. Dabei ist mir aufgefallen, daß der hier beim Start automatisch geladene Default-OSCCAL Wert von 82H noch nicht das Optimum darstellt. Eine kleine Anomalie findet sich im unteren OSCCAL-Einstellbereich: Beim Weiterzählen ist die Taktänderung beim Setzen von Bit0 immer wesentlich kleiner als beim Rücksetzen. Für die Genauigkeit ist natürlich eine Verringerung der Abhängigkeit von Versorgungsspannung- und mehr noch von der Temperatur zwingend. Beides hat sich deutlich verbessert und liegt nun ausreichend bei nur & ungefähr 100kHz Frequenzdrift zwischen 3-5V bzw. 25°C +- 40° = 80°C Differenz (beim Vorgänger um mehr als das Dreifache schlechter). Ein Paukenschlag! Für allgemeine Anwendungen kann jetzt ein Design mit nur noch sehr wenig Beschaltung zum Einsatz kommen (die von mir verwendete, steckbare Variante im Anhang). Als einsetzbare Standard-Frequenz für alle 3 und 5V Anwendungen kalibriere ich auf die bis 115kBAUD UART-0%fehler- und 8Bit Timer Vorteiler-freundlichen 7,3728 MHz hin: Takt via CLKO-Fuse auf PortB0 schalten, mit Programm das den pullgeupten PortD permanent in das OSCCAL-Register einliest, an PortD 8 kleine Schalter Richtung Masse angeschlossen, beabsichtigte Versorgungsspannung dran und am Frequenzmesser auf nahe 7,37 MHz hintrimmen. Spannung/Wert für den Controller notieren und im Programm später Wert manuell in OSCCAL laden. Fertig ist die Laube.
:
Bearbeitet durch User
In der aktuellen Elektor 1/2-2016 findet sich wieder mal ein interessanter Artikel zum Thema.
Wutzi schrieb: > Das wäre jetzt so ein Argument, welches ich bringen würde wenn ich einem > Einsteiger zu 32bit raten würde: Der Aufwand ist am Anfang größer, aber > am Ende des Tages kleiner (vorausgesetzt der Hobbymensch will später mal > was komplexeres bauen). Naja 4x8Bit sind auch 32.... und die heutigen komplexen Sachen beruhen doch massgeblich auf 4/8bit Technik. Somit sind die Grundsysteme doch recht ähnlich zu verstehen und an zu wenden.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.