Hallo,
jetzt habe ich mir einen ATtiny12 bestellt und habe erst dann gemerkt,
dass man den nur in Assembler programmieren kann. Weil der nur einen
Taster einlesen und dann ein Signal ausgeben soll, sollte das
grundsätzlich machbar sein.
Nach ersten Versuchen (Atmel Studio 7) komme ich jetzt aber nicht
weiter. Ich habe folgendes Programm hier, dass erst mal nur ein paar
Pins auf Output setzt und dann nichts mehr macht:
1
.device ATtiny12
2
//#include <avr/io.h>
3
4
// Interrupt-Vektoren
5
.org 0x00
6
rjmp main
7
reti
8
reti
9
reti
10
reti
11
reti
12
13
.org 0x06
14
main:
15
ldi R16, 0b00011001
16
out DDRB, R16 // Output Pins
17
18
ldi R16, 0b00011001
19
out PORTB, R16 // Output Pins auf High
20
21
loop:
22
rjmp loop // Endlosschleife
Das #include ist auskommentiert, da es beim Assemblieren sonst einen
Fehler gibt (Cannot find include file). Ohne das #include läuft der
Assembler durch und erzeugt auch ein List- und ein Hex-File:
1
.device ATtiny12
2
//#include <avr/io.h>
3
4
// Interrupt-Vektoren
5
.org 0x00
6
000000 c005 rjmp main
7
000001 9518 reti
8
000002 9518 reti
9
000003 9518 reti
10
000004 9518 reti
11
000005 9518 reti
12
13
.org 0x06
14
main:
15
000006 e109 ldi R16, 0b00011001
16
000007 bb07 out DDRB, R16 // Output Pins
17
18
000008 e109 ldi R16, 0b00011001
19
000009 bb08 out PORTB, R16 // Output Pins auf High
20
21
loop:
22
00000a cfff rjmp loop // Endlosschleife
Das hex-File kann ich auch ohne Fehlermeldung auf den ATtiny12 hoch
laden, auch ein anschließendes Verify ist in Ordnung.
Nur macht der Controller keinen Mucks, kein Pin geht auf High, egal
welchen ich zu setzen versuche.
Nun zwei Fragen:
1. Warum akzeptiert der Assembler das #include nicht? In vielen
Beispielen, die man im Internet findet ist das drin. Oder muss ich den
Pfad manuell irgendwo hinzufügen?
2. Wo liegt in meinem Programm der Fehler bzw. wie erreiche ich, dass
ein Pin auf High geschaltet wird?
Würde mich freuen, wenn mir dazu jemand Hilfestellung geben könnte.
Vielen Dank schon mal!
Danke für den Hinweis. Das habe ich jetzt auch gleich ausprobiert und
diese Datei ins Projektverzeichnis kopiert und oben im Programmcode
eingebunden:
1
.device ATtiny12
2
.include "tn12def.inc"
Das assembliert ohne Fehler, der in meinem ersten Beitrag zitierte
Abschnitt aus dem Listfile ist aber unverändert, auch die erzeugten
Hex-Codes sind gleich.
Da war dann zu erwarten, dass sich die Ports auch so nicht auf High
schalten lassen, was dann durch Hochladen und Messen leider bestätigt
wurde.
Mark U. schrieb:> Nun zwei Fragen:>> Warum akzeptiert der Assembler das #include nicht? In vielen Beispielen,> die man im Internet findet ist das drin. Oder muss ich den Pfad manuell> irgendwo hinzufügen?
Assembler ist nicht gleich Assembler...
Das #include stammt aus der avrlibc der avr-gcc-toolchain, deren
Assembler avr-as heisst. Wenn du im Studio ein C-Project erstellst, in
dem auch Assemblerdateien genutzt werden, wird der avr-as genutzt.
Reine Assemblerprojekte im Studio nutzen statt dessen den
Atmel/Microchip-Assembler "AVR-Assembler". Der ist halt anders, und
nutzt Atmel files.
Oliver
Mark U. schrieb:> jetzt habe ich mir einen ATtiny12 bestellt und habe erst dann gemerkt
Mouser Electronics schreibt:
End-of-Life-Produkt : Gilt als veraltet und wurde vom Hersteller
abgekündigt
Verstehe.
Also, das Projekt wurde in Atmel Studio 7 als Assembler Projekt
angelegt.
Ich habe da in der Projektverwaltung auch einen Eintrag gefunden, der
einen Include-Pfad zu tn12def.inc enthält.
Das ist dann wohl auch der Grund, warum der Compiler auch ohne eine
Kopie dieser Datei ins Projektverzeichnis durchläuft.
Das Projekt kompiliert ohne Fehler und Warnungen.
Es bleibt also die Frage, warum der Controller nichts macht.
Dazu habe ich auf dieser Seite hier eine Erklärung zu den
Assembler-Befehlen gefunden:
https://trolsoft.ru/en/avr-assembler?cmd=ldi
und
https://trolsoft.ru/en/avr-assembler?cmd=out
Hier nochmal die Zeilen aus dem List-File:
1
000006 e109 ldi R16, 0b00011001
2
000007 bb07 out DDRB, R16
Dabei fällt auf, dass mit dem Befehl ldi das Register R16 mit 0x00
(4Bit) verwendet wird, mit dem Befehl out jedoch mit 0x10 (5 Bit). Das
wird wohl aber schon stimmen, oder?
Ich frage mich halt, ob das Register R16 entweder nicht beschrieben wird
oder der Befehl out an eine falsche Adresse schreibt.
Ja, ich hatte schon versucht, den Simulator aufzurufen. Das funktioniert
aber leider nicht. Für andere Controller gibt es da einen Eintrag, hier
nicht. Evtl. auch, weil es ein Assembler-Projekt ist.
Und ja, ich weiß, dass der Controller abgekündigt ist und es mit einem
andern kleinen Controller einfacher in C zu programmieren wäre. Aber
jetzt habe ich eben diesen hier und würde mich freuen, wenn ich ihn zum
Laufen bekomme.
Hallo,
Mark U. schrieb:> Das hex-File kann ich auch ohne Fehlermeldung auf den ATtiny12 hoch> laden, auch ein anschließendes Verify ist in Ordnung.
Zeig mal wie dein Controller mit dem Programmer verbunden ist.
Ich hatte hier auch mal den Fall das der Controller (ATmega 8) sich
programmieren ließ, der Controller anschließend aber nicht "lief". Der
Grund war banal: ich hatte die Betriebsspannung für den Controller nicht
eingeschaltet.
rhf
Was mag sich der Verfasser bei diesem Literal wohl gedacht haben?...
Antwort: nix. Einfach stumpf geklaut von Code für irgendwelche
8-Beiner-Tinys!
> 2. Wo liegt in meinem Programm der Fehler bzw. wie erreiche ich, dass> ein Pin auf High geschaltet wird?
Nun, das naheliegendste wäre wohl, den korrekten Wert dem Datenblatt zu
entnehmen und dann hinzuschreiben.
Wäre in C übrigens ganz genauso nötig...
Ob S. schrieb:> Was mag sich der Verfasser bei diesem Literal wohl gedacht haben?...>> Antwort: nix. Einfach stumpf geklaut von Code für irgendwelche> 8-Beiner-Tinys!
Was stört dich daran?
Der Code ist für nen Tiny12 gültig.
Jetzt ein Update:
Ich habe obigen Code und die Einstellung des Atmel Studio dahingehend
geändert, dass der Controller ein ATtiny13A ist. Sonst blieb alles
gleich.
Auch damit assembliert der Code. Und noch besser: Der lässt sich jetzt
auch simulieren. Wenn das Programm bei der Endlosschleife ankommt, sind
die Ausgangspins wie erwartet gesetzt, siehe Screenshot. Das Programm
funktioniert also grundsätzlich mal.
Dann habe ich die beiden List-File (also das für den ATtiny12 und das
für den ATtiny13A) miteinander verglichen: Der erzeugte Code ist
identisch. Auch die erzeugten Hex-Files sind gleich.
Dann habe ich aus einem alten Projekt einen ATtiny13A genommen, und den
statt des ATtiny12 eingebaut und programmiert. Und siehe, der ATtiny13A
läuft wie erwartet. Die Hardware sollte also nicht das Problem sein.
Zusammengefasst: Sowohl das Programm als auch meine kleine Hardware
funktionierten mit dem ATtiny13A nicht aber mit dem ATtiny12.
In den Datenblättern der beiden Controller sind die Adressen für DDRB
(0x17) und PORTB (0x18) identisch. Was mich jetzt aber stutzig macht
ist, dass im Simulator für den ATtiny13A andere Adressen angegeben
werden (rot markiert). Da ist ein Offset von 0x20. Muss ich den beim
ATtiny12 irgendwie abziehen? Wie?
Weiß jemand, warum das so ist bzw. könnte das das Problem sein?
Danke und Grüße
Ja, der Reset-Pin hat einen 10k-Pullup.
Den Link bei Stackexchange habe ich mir angesehen, habe die dort
erwähnte Zeile ganz oben eingefügt:
1
#define __SFR_OFFSET 0
Das macht leider keinen Unterschied. So langsam habe ich den Verdacht,
mein Controller hat einen Schaden. Ich werde mir einen neuen bestellen
und dann doch wieder in C programmieren.
Trotzdem vielen Dank für alle Hinweise und Tips.
Hi Mark,
verstehe ich es richtig, das Laden des Hexcodes in den Controller
funktioniert, aber das Programm scheint nicht zu laufen?
Wenn ja: Hast Du einen 100nF zw. VCC und GND beim Attiny? Wenn ja, dann
nevermind, wenn nein: Bei mir hat der damals ((tm) und lang, lang ist es
her) Wunder bewirkt.
Gruß, jois3
Aaalso.
Normalerweise sind die AVRs extrem gut in Assembler programmierbar, die
haben recht viele Befehle in Hardware und anders als die PICs einen
guten Registersatz.
> Dabei fällt auf, dass mit dem Befehl ldi> das Register R16 mit 0x00 (4Bit) verwendet wird,
4 Bit ist Blödsinn, der Befehl lädt immer einen 8-Bit-Wert in das
Register. Wie man diesen Wert nun darstellt, ob dezimal, hexadezimal
oder binär spielt keine Rolle. Ich glaube, es wäre sogar ein Zeichen als
String möglich, aber es bleiben immer 8 Bit.
> mit dem Befehl out jedoch mit 0x10 (5 Bit).
Das sollte bei den kleinen AVRs immer passen, die können mit OUT alle
Hardware-Register erreichen. Bei den größeren AVRs sind so viele
Funktionen und damit verbundene Hardware-Register hinzugekommen, daß
sich die oberen anstatt mit IN/OUT nur noch mit LDS/STS erreichen
lassen, so als würde man aufs RAM schreiben. Für den ATTiny12 sollte das
egal sein.
Wenn Du keine Interrupts benutzt,
brauchst Du auch keine Interrupttabelle.
Probier mal:
Die ATtiny12 sind uralt und haben folgenden Design-Nachteil:
Es gibt kein RAM! Deshalb geht auch nur ASM Programmierung.
Dein Prog nutzt die CPU Register, daher ist das wohl nicht relevant.
ABER, die ATtiny12 die ich in der Zeit der Chipknappheit gekauft hatte
waren eine Katastrophe! Diese ließen sich kaum Programmieren. Mutmaßlich
weil die Flashzellen aufgrund des Alters der ICs nicht mehr richtig
funktionieren.
Nur mit einem superlangsamen Takt von 2kHz und auch erst nach mehreren
Versuchen klappte es dann doch.
Meine dringende Empfehlung, nutze ATtiny13 oder besser etwas noch
aktuelleres.
Mark U. schrieb:> Zusammengefasst: Sowohl das Programm als auch meine kleine Hardware> funktionierten mit dem ATtiny13A nicht aber mit dem ATtiny12.
Lustig, welchen Interpretationsspielraum so ein fehlendes Komma
schafft... ;-)
Variante 1:
> funktionierten mit dem ATtiny13A nicht, aber mit dem ATtiny12.
Variante 2:
> funktionierten mit dem ATtiny13A, nicht aber mit dem ATtiny12.
Ben B. schrieb:>> Dabei fällt auf, dass mit dem Befehl ldi>> das Register R16 mit 0x00 (4Bit) verwendet wird,> 4 Bit ist Blödsinn, der Befehl lädt immer einen 8-Bit-Wert in das> Register.
Die LDI Instruktion codiert sowohl den zu ladenden Wert als auch das
Zielregister. Für den Wert codieren 8 Bits, und für das Zielregister
R16...R31 codieren 4 Bits.
Oliver D. schrieb:> Meine dringende Empfehlung, nutze ATtiny13 oder besser etwas noch> aktuelleres.
Es war bei diesem komischen Thread leider auch mein erster Gedanke oder
Überlegung, warum sich die Leute immer wieder mit diesen verkümmerten
µControllern und Überresten oder Leichen selbst quälen, um irgendetwas
mit µControllern – beispielsweise den Einstieg oder Wiedereinstieg – zu
machen. Wie ich bereits in einem ähnlichen Fall mit ähnlicher
Selbstquälerei schrieb – es gibt auch ATTINY85, ATTINY84 oder gar
ATMEGA328P – alle auch in PDIP, den erstgenannten gibt es sogar auch als
PDIP8, man kann sie sowohl in Assembler als auch in C programmieren, da
hier immer reichlich SRAM vorhanden ist und der Compiler damit im
Hintergrund arbeiten kann. Aber das Muster wiederholt sich immer – man
will immer schön mit dem Kopf durch die Wand bis der Arzt kommt. Ferner
schrieb ich auch, dass ein sehr einfacher, kleiner µC genauso
problematisch wie ein größerer sein kann – und das ist hier genau so ein
Fall, denn ohne SRAM muss selbst der Mensch in Assembler eine komische
Gymnastik mit Registern machen und sie für diese Zwecke entfremden,
damit das alles überhaupt funktionieren kann. Diese extrem kleinen,
beschnittenen ATTINY-µC sollte man nur dann nehmen, wenn man sie
explizit braucht und auch ganz genau weiß, was man da tut.
Hinzu kommt noch immer wieder die Hardwareseite der Geschichte wie
Aufbau und Ausrüstung etc. zum Vorschein oder fordert ihren Tribut –
statt 50-60 Euro in einen vernünftigen Programmer zu investieren, um
sich vom Atmel-Studio-7 direkt mit dem jeweiligen µController zu
verbinden und alles sofort zu sehen und unter Kontrolle zu haben, vor
allem die Fuses und ob der µC überhaupt lebt, wird irgendein Mist für 5
Euro auf Ali & Co. aus Geizgründen gekauft und man versucht dann damit
über Umwege und komischen Aufbau seine generierten Hex-Filechen auf
kryptische Weise und oft ohne eine wirkliche, reale Rückmeldung in den
µC zu schieben. Es wird auch gar nicht richtig gezeigt, was man da zu
Hause eigentlich versucht und macht, sondern es beginnt dann das große
Blindekuh-Spiel im Thread, wo dann alle nacheinander versuchen, blind
dem Blinden zu „helfen”. Zum Schluss noch ein Trost: wenn es hier dann
mit dem Attiny12 und dem 5-Zeilenprogramm endlich klappt, wird man am
Ende der absurden Odyssee sehr schnell feststellen müssen, dass auch der
Flashspeicher sehr schnell ziemlich knapp wird, wenn man doch ein
richtiges Programm schreiben will, denn bei 1 Kilobyte sind es nur 512
einfache Befehle wie NOP, CLR oder ADD, bei größeren Befehlen wird
daraus noch deutlich weniger und die Pseudo-Vektortabelle am Anfang des
Flashs muss man davon auch noch abziehen; wenn man dann noch ein paar
Daten im Flash ablegen will, dann gute Nacht Thaddäus. Aber es steht
natürlich jedem frei, sich selbst und – bedingt durch diese
Vorgehensweise – auch andere in diesen Strudel des Wahnsinns
hineinzuziehen und als Kollateralschaden somit auch zu quälen.
Viel gelabert, nichts gesagt.
Es ist doch nichts neues, daß man den Controller passend zur Aufgabe
wählen muss. Der Registersatz beim AVR ist wie ich bereits angesprochen
habe, ziemlich gut. Gewissermaßen hat man da 32 Byte RAM. Für
irgendwelche einfachen Aufgaben wie einen programmierbaren Timer oder
einen Timer mit irgendwelchen Logikfunktionen reicht das locker, da
brauche ich keinen STM32 oder so für nehmen. Auch das eine Kilobyte
Flash wird dafür locker reichen, solange man keine größere Menge an
Daten bzw. Tabellen für irgendwas braucht. Es besteht auch keine
Notwendigkeit, Daten im Flash abzulegen - der ATTiny12 hat 64 Bytes
EEPROM dafür.
Gregor J. schrieb:> warum sich die Leute immer wieder mit diesen verkümmerten µControllern> und Überresten oder Leichen selbst quälen, um irgendetwas mit> µControllern – beispielsweise den Einstieg oder Wiedereinstieg – zu> machen.
Wenns nur ein paar dutzend Zeilen Assembler für die Anwendung braucht,
ist ein Tiny12 sicher nicht unterdimensioniert.
Oliver
Oliver S. schrieb:> Wenns nur ein paar dutzend Zeilen Assembler für die Anwendung braucht,> ist ein Tiny12 sicher nicht unterdimensioniert.
Es würde sogar noch kleiner mit einem AVR in SOT23-6 gehen, wenn man
versiert ist und die Programmierung samt allem, was drumherum dazu nötig
ist, beherrscht, hier scheint das aber nicht der Fall zu sein, insofern
ein klassischer Fehlgriff in die in diesem Forum so berühmte
„Bastelkiste”. Aus welchen Gründen auch immer – und oft ist es die „Geiz
ist geil Mentalität” oder weil etwas altes in der Schublade lag, was die
Entscheidungen maßgeblich definiert – einfach wieder mal in die falsche
Schublade gegriffen, aber das darf jeder selbst feststellen.
Georg M. schrieb:> Seit es den ATtiny412 gibt, ist der dürftige ATtiny13A nicht mehr> erwähnenswert.
Viele kommen mit der neueren AVR-Architektur nicht klar und wenn jemand
die alten ATTINY registermäßig gar nicht oder nur rudimentär beherrscht
oder generell meint, diese durch „Copy & Paste” von Codeteilen
beherrschen zu können, so wird er in der Regel die neueren
Registeransätze gar nicht verstehen oder mögen können, denn die
Komplexität der Peripherieregister geht ein wenig in Richtung STM32 –
das beginnt schon mit den Portregistern und mit der Innovation, wie man
die I/Os der Ports einstellen und unterschiedlich ansprechen kann, über
Virtual Ports etc. Ein AVR128DB28 sieht z.B. von außen genauso wie ein
ATMEGA328P aus, ist aber – obwohl die CPU an sich fast identisch
arbeitet – im Inneren völlig anders aufgebaut, das Drumherum ist quasi
ein deutlich komplexer Neuentwurf. In so einem Fall bleibt einem
Kandidaten nichts anderes übrig als bei den alten ATTINY-ICs zu bleiben,
allein schon das neue UPDI-Interface macht einem „Ali-1Euro-Käufer” oft
einen Strich durch die Rechnung.
Gregor J. schrieb:> denn bei 1 Kilobyte sind es nur 512 einfache Befehle wie NOP,> CLR oder ADD, bei größeren Befehlen wird daraus noch deutlich> weniger
Immerhin, größere, also 32-Bit Befehle, braucht man ohnehin nicht:
* LDS / STS braucht man nicht da es eh kein RAM gibt, und für
den I/O Bereich genügen IN und OUT.
* CALL / JMP braucht man wegen des kleinen Programmspeichers auch
nicht, bzw werden erst garnicht unterstützt.
Johann L. schrieb:> Immerhin, größere, also 32-Bit Befehler, braucht man ohnehin nicht:
Es ist durchaus möglich, dass durch den extrem kleinen Adressraum alle
Befehle innerhalb von 16 Bit codiert werden können und so quasi alles
„orthogonal” bleibt, bei RISC-Architektur hat man allerdings das
Problem, dass bei vielen Befehlen über zwei Befehle gegangen werden
muss, weil das – bedingt durch die Reduzierung des Befehlssatzes –
meistens über ein Registerladen geht, und somit dann hier für einen
Vorgang oft zwei Befehle (also 2x 16-Bit) benötigt werden, was die
Anzahl an maximal möglichen 512 Befehlen in einem 1KB-Speicher immer
signifikant reduzieren wird. Möchte man Subroutinen im Code haben, für
z.B. verschiedene Delays und eventuell um ein paar komplexere
Zahlenberechnungen mit größeren Integern anzustellen, wird der noch
vorhandene Platz immer kleiner.
Gregor J. schrieb:> Johann L. schrieb:>> Immerhin, größere, also 32-Bit Befehler, braucht man ohnehin nicht:>> Es ist durchaus möglich, dass durch den extrem kleinen Adressraum alle> Befehle innerhalb von 16 Bit codiert werden können und so quasi alles> „orthogonal” bleibt, bei RISC-Architektur hat man allerdings das> Problem, dass bei vielen Befehlen über zwei Befehle gegangen werden> muss
Nicht bei AVR. Die einzigen 32-Bit Befehle sind LDS, STS, CALL und JMP,
die wie erklärt auf ATtiny12 nicht gebraucht werden bzw. ohnehin nicht
unterstützt werden.
Johann L. schrieb:> Nicht bei AVR. Die einzigen 32-Bit Befehle sind LDS, STS, CALL und JMP,> die wie erklärt auf ATtiny12 nicht gebraucht werden bzw. ohnehin nicht> unterstützt werden.
Falls man nicht verstanden hat, was gemeint war, hier unten ein Zitat
und Beispiel gleich aus dem ersten Post des Autors – und ich lege sogar
noch nach: man muss sogar sehr oft so unfreiwillig über zwei Befehle –
also insgesamt 32-Bit – gehen, um einen Vorgang durchzuführen.
1
000006 e109 ldi R16, 0b00011001
2
000007 bb07 out DDRB, R16 // Output Pins
3
4
000008 e109 ldi R16, 0b00011001
5
000009 bb08 out PORTB, R16 // Output Pins auf High
Gregor J. schrieb:> Möchte man Subroutinen im Code haben, für> z.B. verschiedene Delays und eventuell um ein paar komplexere> Zahlenberechnungen mit größeren Integern anzustellen, wird der noch> vorhandene Platz immer kleiner.
Man kann damit durchaus komplexere Programme schreiben, z.B.:
Beitrag "DCF77-Uhr mit ATTINY12"
Man spart sogar Flash, da alle Variablen in Registern vorliegen (kein
PUSH, POP, LDS, STS nötig). Allerdings zwingt der begrenzte
Hardwarestack zu einigen Kompromissen.
> 000009 bb08 out PORTB, R16 // Output Pins auf High
6
>
>> Oder einfach:>>
1
> 000006 e109 ldi R16, 0b00011001
2
> 000007 bb07 out DDRB, R16 // Output Pins
3
> 000009 bb08 out PORTB, R16 // Output Pins auf High
4
>
Man kann den Code später u.a. so optimieren, wenn es gerade so von den
Werten passt, erfahrungsgemäß passt es oft aber leider nicht. Ferner
wird dem Codemanipulator empfohlen, wenigsten die Orginalversion
auskommentiert im Code zu lassen und es entsprechend in einem Kommentar
zu erwähnen, um später nicht grübeln zu müssen und es wieder schnell
rückgängig zu machen, falls die Werte doch verschieden sein sollten.
Peter D. schrieb:> Man kann damit durchaus komplexere Programme schreiben (...)
Ich habe nicht behauptet, dass es nicht geht, sondern, dass es knapp
wird und man sich mit einem µC mit so knappen Ressourcen unnötig selbst
Probleme bereitet. Gerade dann, wenn man Assembler nicht kann, kann es
zu unüberwindbaren Problemen führen.
Immer diese Diskussion, welcher Controller nun der beste oder der
geeignetste ist, ohne daß man genau weiß, was der TE überhaupt vor hat.
Aber eine Sache dazu: Diese neue AVR-Architektur halte ich für eine
Totgeburt. Wenn ich da vieles neu oder umlernen müsste, dann wechsle ich
garantiert nicht von AVR-alt auf AVR-neu, sondern von AVR auf ARM Cortex
M0 oder M3. Oder eben gleich C-only, dann spielt die Architektur des µC
nur noch eine untergeordnete Rolle insofern der Compiler das gewünschte
Spektrum abdeckt.
Ben B. schrieb:> Oder eben gleich C-only, dann spielt die Architektur des µC> nur noch eine untergeordnete Rolle insofern der Compiler das gewünschte> Spektrum abdeckt.
Nein, leider falsch gedacht, sie spielt keine untergeordnete Rolle –
egal ob in Assembler oder C, die Arbeit zu den Registern, die
angesprochen werden müssen und über die man sich informieren muss, muss
in beiden Fällen erledigt werden. Selbst wenn es für die AVR so etwas
wie in der STM32CubeIDE für die STM32 zum Zusammenklicken und
Vorkonfigurieren gibt, sollte man sich mit der Peripherie
auseinandersetzen, um sie adäquat verstehen und nutzen zu können.
________> Diese neue AVR-Architektur halte ich für eine Totgeburt.
Schauen wir mal, was sich im Laufe der Zeit als Totgeburt herausstellt –
Deine Worte oder die neue AVR-Architektur.
Gerne. Es ist aber schon 'ne ganze Weile her, daß ich bei irgendwelchen
Geräten, die ich so zerlegt habe, 'nen AVR - egal ob alt oder neu - drin
gefunden habe. Dafür jede Menge STM32-irgendwas oder deren Klone.
Ben B. schrieb:> Gerne. Es ist aber schon 'ne ganze Weile her, daß ich bei irgendwelchen> Geräten, die ich so zerlegt habe, 'nen AVR - egal ob alt oder neu - drin> gefunden habe. Dafür jede Menge STM32-irgendwas oder deren Klone.
Dein Vergleich oder Deine Analogie hinkt – Du vergleichst Äpfel mit
Birnen. Die Welt und der Markt sind viel komplexer, um mithilfe so einer
vereinfachten Sichtweise diese Schlussfolgerung abzuleiten.
Ben B. schrieb:> Immer diese Diskussion, welcher Controller nun der beste oder der> geeignetste ist, ohne daß man genau weiß, was der TE überhaupt vor hat.>> Aber eine Sache dazu: Diese neue AVR-Architektur halte ich für eine> Totgeburt. Wenn ich da vieles neu oder umlernen müsste, dann wechsle ich> garantiert nicht von AVR-alt auf AVR-neu, sondern von AVR auf ARM Cortex> M0 oder M3. Oder eben gleich C-only, dann spielt die Architektur des µC> nur noch eine untergeordnete Rolle insofern der Compiler das gewünschte> Spektrum abdeckt.
Na ja, es gibt halt eine ganze Menge Leute, die schlauer sind als Du und
mit dem Lernen keine Probleme haben. Du bist aber auch nicht der
Maßstab.
Die neuen Serien haben einige Vorteile, die die Industriekunden haben
wollen. Z.B. die Entkopplung der IO-Spannung von der Kernspannung. Die
Teile laufen über den gesamten Spannungsbereich mit vollem Takt, weil
der Kern eben immer nur mit z.B. 1.8V läuft. Kleinere Transistoren sind
halt schneller. Bei den 8-Bit PICs ist das schon seit einem Jahrzehnt
so. Oder das Einblenden des Programspeichers in den Datenadressraum. Das
erlaubt einfache Pointeroperationen statt (E)LPM. Das hat PIC24 z.B.
seit Anfang an mit dem PSW (Program Space Window). Oder der Verzicht auf
DIL-Packages. Braucht in der Industrie kaum noch jemand. Viel zu teuer
in der Bestückung.
Wer die Rechnung bezahlt, bestimmt, was gespielt wird.
Und was zahlst DU?
fchk
Ben B. schrieb:> Wenn ich da vieles neu oder umlernen müsste, dann wechsle ich> garantiert nicht von AVR-alt auf AVR-neu, sondern von AVR auf ARM Cortex> M0 oder M3.
Dass ich in der Komplexität des Registeraufbaus der neuen AVRs
ansatzweise Züge des Registeraufbaus der STM32 gefunden habe, heißt
leider nicht automatisch, dass der Einstieg in die STM32-Welt genauso
einfach wie der Einstieg in die Welt der neuen AVRs sein wird, selbst
mit dem einfachsten STM32F030 wird es nicht so einfach sein, aber das
weiß man sofort, wenn man mit der schwerverdaulichen Materie anfängt und
sich vorab z.B. schon mal ein wenig mit den Datenblättern befasst. Der
Plural des Substantivs hier ist leider kein Schreibfehler und der Umfang
der Dokumentationen ist deutlich größer – bei den 8-Bit-AVRs ist das
alles in der Regel in einem überschaubar kurzen oder langen Datenblatt
eingekapselt.
Ben B. schrieb:> dann wechsle ich> garantiert nicht von AVR-alt auf AVR-neu, sondern von AVR auf ARM Cortex> M0 oder M3.
Habe ich das richtig verstanden: Es kann entweder der NE555 oder ein ARM
Cortex-M sein, und nichts dazwischen?
Ben B. schrieb:> Oder eben gleich C-only, dann spielt die Architektur des µC> nur noch eine untergeordnete Rolle insofern der Compiler das gewünschte> Spektrum abdeckt.
Es gibt sehr viele unterschiedliche Mikrocontroller, weil sie
unterschiedlich sind, weil ihre Komponenten unterschiedlich sind: Timer,
ADC, DAC, AC, Vʀᴇꜰ, interne Oszillatoren, Connectivity, Power
Management, etc. etc. etc. Die Kenntnis von Programmiersprachen allein
reicht nicht aus: man muss auch das Datenblatt lesen.
> Habe ich das richtig verstanden: Es kann entweder der NE555> oder ein ARM Cortex-M sein, und nichts dazwischen?
Ja natürlich hast Du das richtig missverstanden,
für diese großartige Leistung darf man Dich durchaus beglückwünschen.
Ich bin der Meinung, daß die älteren AVR-Kerne dafür völlig ausreichend
sind. Und naja, die kleineren ARM Cortex sind heute ähnlich preiswert
wie ein NE555.
Ich hätte mich mehr darüber gefreut, wenn sie den älteren AVR-Kernen
etwas bessere Hardware gegönnt hätten. Vielleicht einen höheren Takt,
schnellere Timer (bekommt man nur bei einer kleinen Auswahl, nicht bei
allen AVRs), D/A-Wandler oder besser auflösende A/D-Wandler,
USB-Fähigkeit. So wie man das im Wesentlichen beim 8051 gemacht hat.
Hallo,
jetzt will ich das Thema hier abschließen. Inzwischen habe ich einen
ATtiny13A bestellt. Den kann ich in C programmieren und die Schaltung
funktioniert damit.
Weil ich aber neugierig war, ob nun wirklich der ATtiny12 ein Problem
hatte, habe ich mir auch davon einen mitbestellt. Den habe ich mit dem
ursprünglichen Assembler Code programmiert und siehe da, auch damit
läuft die Schaltung. Also waren die Schaltung und auch das Assembler
Programm in Ordnung und das Problem lag offenbar beim ersten ATtiny12,
der einen Defekt hatte.
Mark U. schrieb:> Also waren die Schaltung und auch das Assembler Programm in Ordnung und> das Problem lag offenbar beim ersten ATtiny12, der einen Defekt hatte.
Danke für den Nachtrag - hatte gerade diesen Thread zufällig gefunden
und mit Interesse überflogen.
Kurioserweise hatte ich mich die letzten Tage auch etwas mit dem
ATtiny12 beschäftigt, aber ohne ein Exemplar davon zu besitzen -
lediglich dessen ISP-Schnittstelle war für mich interessant, da dieser
die RDY/BSY-Instruktion fehlt und dadurch das Testen von Value Polling
mit avrdude ermöglicht wird.
Mit der Programmierschnittstelle habe ich mich gar nicht befasst und
kann dazu leider auch nichts sagen.
Insgesamt ist es schon so, dass der ATtiny12 mal interessant für ein
kleines Assembler-Projekt ist. Aber viel mehr als eine LED blinken zu
lassen ist für mich dann doch zu aufwendig. Und so bin ich mit dem
ATtiny13A jetzt wahrscheinlich besser beraten.
Mark U. schrieb:> Mit der Programmierschnittstelle habe ich mich gar nicht befasst und> kann dazu leider auch nichts sagen.
War nur eine Randbemerkung von mir. Mir ging es nur darum, dass mein
Selfmade-AVRISP-Dongle auch den alten Tiny12 mit seinem abgespeckten
ISP-Befehlssatz korrekt unterstützt.
Thread beobachten
Seitenaufteilung abschalten