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:
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?
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.
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.
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.
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.
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.
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.
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?
"How to solve the issue? You can override the switch by defining the offset yourself in your ASM code, before avr/io.h is included: #define __SFR_OFFSET 0."
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
