Ganz nebenbei fällt mir etwas auf:
Beim neuerlichen Assemblieren eines älteren Programms, das für den ATiny4313 geschrieben wurde, meldet der "Assembler": "kein SPH vorhanden". "Assembly failed". Obwohl früher das ohne Fehlermeldung durchging. Die include-Datei aus Assembler2 lautet nach wie vor "tn4313def.inc".
Das Programm selbst läuft nach Assemblieren, wenn die Zeilen zum Setzen des SPH herausgelöscht worden sind, fehlerfrei.
Es sieht so aus, dass die explizite Angabe für SPH einen Fehler darstellt, der aber von den Assembler-Versionen früher (oder später) schlichtweg ignoriert worden ist.
Tatsächlich ist die Endadresse 5D. Also 256 Byte SRAM sind verfügbar auch mit Deklaration
"nur" SPL.
Die neu aufgesetzte Programmierumgebung von Atmel hört auf den Namen Atmel AVR Studio 4.17 666.
Bei Anklicken der Installations.exe kommt normalerweise "Ein Administrator hat das Programm geblockt."
Es gibt aber Tricks, die Blockierung zu umgehen, so dass auch Windows 11 mitspielt.
Wenn da versehentlich in einer älteren Version der Include-Datei eins war, lief das natürlich früher durch. Vermutlich passiert trotz "Reserved" einfach nichts, wenn man auf die entsprechende Register-Adresse zugreift.
Wenn da versehentlich in einer älteren Version der Include-Datei eins
war, lief das natürlich früher durch.
Ja, auch bei dem tn4313def.inc des Studio 4.18 gibt's SPH.
Und ich vermute ganz stark: das ist korrekt so.
Im DB (einem, was die Existenz von SPH abstreitet) steht nämlich, dass SPL zwingend auf eine Adresse >0x60 zu initialisieren wäre. Diese Einschränkung macht aber wenig bis keinen Sinn, wenn es kein SPH gäbe.
Entweder ist SPL mit Wrap-Around implementiert, dann sollte der Initialisierungswert keine Rolle spielen, denn 0x5f z.B. entspräche eben 0x15f realer SRAM-Adresse.
Oder es gibt keinen Wrap-Around, dann ergibt zwar die genannte Einschränkung einen Sinn, aber nur in Kombination mit SPH.
Zumindest wäre es dann aber ohne SPH völlig unmöglich, den Stack auf RAMEND zu initialisieren.
Wie auch immer: was nun stimmt, sollte sich mit realer Hardware sehr leicht überprüfen lassen.
Ich hätte sogar noch 2x 4313 rumliegen, aber leider keinen passenden Adapter greifbar, um auf die Schnelle mal so einen Test zu machen. Und zum Löten habe ich heute abend keine Lust mehr.
Im DB (einem, was die Existenz von SPH abstreitet) steht nämlich, dass
SPL zwingend auf eine Adresse >0x60 zu initialisieren wäre.
Das steht eh in allen (älteren) AVR-Datenblättern drin.
Beim originalen ATtiny2313-Datenblatt stand sogar noch der Stackpointer generisch als aus zwei Registern bestehend und danach dann der Nachsatz, dass er bei einigen kleineren AVRs nur aus einem besteht.
Das steht eh in allen (älteren) AVR-Datenblättern drin.
Ja klar.
Die Frage ist aber nun doch, wie sich das beim 4313 genau verhält. Ist das SPH-Register nicht vorhanden bzw. funktionslos, dann gibt es zwei Varianten, wie SPL zu initialisieren ist, um den Stack auf RAMTOP (nicht RAMEND, wie ich fälschlicherweise schrieb) zu setzen. Nämlich 0xff oder 0x5f. Was davon ist korrekt?
Die dritte Variante wäre halt, dass sich der Stack überhaupt nicht auf RAMTOP initialisieren läßt. Und das ist kaum vorstellbar.
Beim originalen ATtiny2313-Datenblatt stand sogar noch der Stackpointer
generisch als aus zwei Registern bestehend und danach dann der Nachsatz,
dass er bei einigen kleineren AVRs nur aus einem besteht.
Das mag sein.
In den alten Includes der 4er-Studios ist allerdings das Register beim 2313 und beim 2313A nicht enthalten (weil natürlich auch nicht nötig), beim 4313 aber sehr wohl.
Ich vermute ganz stark, dass die ganze Verwirrung durch das beschissene gemeinsame DB für 2313A/4313 ausgelöst wurde. Da taucht der 4313 bei der Beschreibungs des Stacks nicht explizit auf. Alles andere (insbesondere auch neuere Includes) sind wohl Folgefehler dieses beschissenen DB.
Beweisen kann ich das derzeit nicht, aber so bald ich mal ein wenig Zeit habe, um ein paar Drähte anzulöten, werde ich die Auflösung des Rätsels nachliefern. Nicht, dass das heute für mich noch wichtig wäre, aber da ich nun schonmal zufällig zwei von den Teilen noch rumliegen habe...
Dann habe ich noch herausgefunden, dass man von der Microchipseite
Atmel.ATtiny_DFP.2.1.484.atpack herunterladen,
in *. zip umbenennen und "normal" entpacken kann.
Die dortige def.inc mit Veröffentlichungsdatum
Created: 2011-02-09 12:04 ******* Source: ATtiny4313.xml
in den entsprechenden Pfad kopieren, nachdem die "alte" def.inc umbenannt wurde.
Ergebnis:
Mit der "neuen" tn4313def.inc kommt keine Fehlermeldung mehr.
Also wieder ein Ereignis, das sich auf die Verwendung der jeweils tatsächlich verwendeten Definitionsdatei bezieht.
Und bei Verwendung einer bestimmten Version von Atmel Studio auftreten kann.
Wieso ausgerechnet die 17-er Version?
Bei der Version 4.19 "löschte" sich das geflashte File von "selbst wieder weg". Auch bei korrekt gesetztem Brownout etc. Offensichtlich wurde es nur gecached und garnicht ins Flash geschrieben. Programm lief nur so lange, wie die Betriebsspannung direkt nach Flashvorgang noch vorhanden war. Bei Power Cyclen war File verschwunden.
Diese "Unart" hat die Version 4.17 (noch) nicht. Daher die "ältere" Version installiert.
Läuft zwar auch nicht ganz stabil unter Win11, aber immerhin noch handhabbar.
Bei der Version 4.19 "löschte" sich das geflashte File von "selbst
wieder weg". Auch bei korrekt gesetztem Brownout etc. Offensichtlich
wurde es nur gecached und garnicht ins Flash geschrieben.
Das ist technisch unmöglich. Von wo soll es sonst ausgeführt worden sein?
Es ist interessant, dass Du immer alle Probleme, die meistens nur bei Dir auftreten, direkt auf Bugs (also Fehler anderer) schiebst, obwohl bei Dir ziemlich offensichtlich ist, dass die meisten Probleme vor der Tastatur entstehen.
Das ist technisch unmöglich. Von wo soll es sonst ausgeführt worden
sein?
Eine weitere Ursachenforschung in der Richtung (Problem: wieso Programm verschwindet) wäre unnötige Zeitverschwndung, wenn kurzfristig eine andere Lösung praktikabler ist.
Jedenfall sind Über 900 MB an Installationsdatei und 6 GB an Speicher für das anempfohlene Nachfolgeprogramm MPLAB für meine Zwecke schlichtweg der absolute Overkill.
Schadet ja nicht, wenn man es einmal mit einer Studio 4-Version unter Win11 probiert. Mehr als "Programm wurde von einem Administrator geblockt", ein "Nicht-Funktionieren" oder Auftauchen ominöser Fehlermeldungen kann ja nicht passieren.
Falls es da weiter Probleme gibt, nehme ich eben den Rechner mit XP. Aber den krame ich nicht jedesmal raus.
Auch wenn ich ja ein Fan von Datenblättern bin, wirds in dem Fall wohl doch ein SPH mit einem gültigen Bit geben müssen. Die 256 Byte Sram sind ja ansonsten nicht vollständig zu adressieren.
Auch wenn ich ja ein Fan von Datenblättern bin, wirds in dem Fall wohl
doch ein SPH mit einem gültigen Bit geben müssen. Die 256 Byte Sram sind
ja ansonsten nicht vollständig zu adressieren.
Oliver
Wirst du wohl Recht haben, die haben einfach den '4313 mit ins '2313er Datenblatt gepackt und dabei nicht alle Stellen erwischt, die sie hätten ändern müssen.
Ich hatte mal geschaut, avr-libc initialisiert den Stackpointer (standardmäßig) auf 0x15F.
Moin,
warum kann man mit einem Byte keine 256 Byte SRAM adressieren?
Wenn man bei Adresse 0 anfängt ja, sonst nicht.
Da Carsten-Peter vermutlich das AVR-Konzept nicht ganz klar sein dürfte: der SRAM bei AVRs fängt halt nicht bei 0 an, weil davor noch die IO-Register liegen (und bei diesen historischen AVRs außerdem noch via RAM-Adressen zugreifbare CPU-Register).
warum kann man mit einem Byte keine 256 Byte SRAM adressieren?
Kann man zwar, wird m.W. beim ATtiny4313 (oder anderen AVRs) aber nicht gemacht. Würde bedeuten, dass die zu SP gehörige 16-Bit RAM Adresse als
1
addr=SPL+256*(SPL<0x60)// 1
oder als
1
addr=0x60+SPL// 2
zu berechnen wäre. Weder das eine noch das andere ist der Fall. Zumindest gab's die letzten 25 Jahre keinen entsprechenden Bug-Report gegen GCC dass der Frame-Pointer falsch bestimmt werden würde :-)
GCC nimmt einfach
1
addr=SP// 3
weil ATtiny4313 als 16-Bit SP gelistet ist — im Gegensatz zu ATtiny2313, wo das High-Byte als 0 genommen wird statt SPH auszulesen.
ein Auszug aus einem laufenden Programm in Assembler:
Das läuft auf einem Simulator. Sowas zur Verfizierung einer Hardware-Eigenschaft zu benutzen, ist eine ziemlich blöde Idee. Auch Simulatoren können nämlich Bugs haben. Und in der Tat gibt es sogar etliche bekannte Bugs der in den Studios enthaltenen Simulatoren. Das fängt schon damit an, dass etliche Teile der Peripherie überhaupt nicht simuliert werden.
Es ging darum, nochmal die alten Dinger neu zu flashen. Ohne bombastischen Aufwand zu betreiben. Wenn ich einen Oldtimer möglichst originalgetreu restaurieren will, baue ich auch keine "heute" gängigen Teile ein. Ob er dann eine TÜV-Zulassung bekommt oder ein H-Kennzeichen, steht auf einem anderen Blatt.
Wer verbietet mir eigentlich ernsthaft, einen AtTiny2313 zu verwenden?
Von Arduino und Konsorten habe ich auch schon gehört. Und arbeite auch gerne damit. Nützt mir aber nichts für die 2008 erstellten Programme.
Beispiel Netzuhr.
Trotzdem danke für die zahlreiche Teilnahme am Thread.
Und mit Win11 kann es mit den alten Programmiertools auch klappen, wenn auch gelegentlich mit Haken und Ösen. Kommt nur auf den Versuch an.
Beweisen kann ich das derzeit nicht, aber so bald ich mal ein wenig Zeit
habe, um ein paar Drähte anzulöten, werde ich die Auflösung des Rätsels
nachliefern. Nicht, dass das heute für mich noch wichtig wäre, aber da
ich nun schonmal zufällig zwei von den Teilen noch rumliegen habe...
Also, heute hat es sich ergeben, dass ich eh' privat am Löten war. Ich habe also mit echter Hardware verifzieren können:
Ja, beim 4313 existiert SPH.
Wird automatisch beim Reset auf RAMEND (das High-Byte davon, also 1) initialisiert
Läßt sich auch per Software schreiben und agiert wie erwartbar und gewohnt.
Ich hatte mal geschaut, avr-libc initialisiert den Stackpointer
(standardmäßig) auf 0x15F.
In diesem Fall unnötigerweise... 2313A/4313 machen das von Hause aus in Hardware. Sagt da auch das DB (naja, sagt es zumindest für SPL). Der 2313 (ohne A) hingegen macht das noch nicht. Der braucht tatsächlich die Initialisierung per Software.
Ich hatte mal geschaut, avr-libc initialisiert den Stackpointer
(standardmäßig) auf 0x15F.
In diesem Fall unnötigerweise... 2313A/4313 machen das von Hause aus in
Hardware.
Naja, für die paar Byte, die das ausmacht, lohnt sich die Fallunterscheidung, für welche AVRs man es unbedingt braucht und für welche nicht, nicht wirklich. Kommt hinzu, dass das Framework (AVR-LibC + Linkerscripte) es halt problemlos gestattet, dass man zur Linkzeit den Stack alternativ auf einen anderen Wert als RAMEND initialisieren lassen kann.
Naja, für die paar Byte, die das ausmacht, lohnt sich die
Fallunterscheidung, für welche AVRs man es unbedingt braucht und für
welche nicht, nicht wirklich.
Naja, das siehst du anders, wenn dir 1..4 Bytes bei einer konkreten Anwendung fehlen. Was gerade bei diesem Tiny-Kram ja durchaus mal passieren könnte...
Kommt hinzu, dass das Framework (AVR-LibC
Linkerscripte) es halt problemlos gestattet, dass man zur Linkzeit den
Stack alternativ auf einen anderen Wert als RAMEND initialisieren lassen
kann.
Nettes Feature. Aber wie alle netten Features sollte der Footprint eben idealerweise genau nur dann auftreten, wenn er auch tatsächlich nötig ist.
Kommt hinzu, dass das Framework (AVR-LibC
Linkerscripte) es halt problemlos gestattet, dass man zur Linkzeit den
Stack alternativ auf einen anderen Wert als RAMEND initialisieren lassen
kann.
Nettes Feature. Aber wie alle netten Features sollte der Footprint eben
idealerweise genau nur dann auftreten, wenn er auch tatsächlich nötig
ist.
Kannst du gern bauen, wenn du denkst, dass das den Aufwand lohnt. Ist Opensource, Patches welcome.
Kannst du gern bauen, wenn du denkst, dass das den Aufwand lohnt.
Das denke ich sicher nicht. Wenn ich nicht zufällig diese Teile noch in der Bastelkiste rumliegen gehabt hätte, hätte ich mich garnicht weiter mit dem Thema beschäftigt.
Danke!
Trotz Angabe von SPL und SPH und fehlerfreiem Assemblieren ist noch etwas zu bemerken.
Im "Simulator" ist nur SPL zu sehen. Aber das ist nebensächlich, weil dadurch das Erstellen des Hex-Files nicht beeinflusst wird. Wie gesagt, bei der "falschen" INC wurde kein Hex-File erstellt. Die richtigen Files findet man wie oben angegeben. Beitrag "Re: Atmel AVR Fehlermeldung SPH nicht vorhanden"
Klar, weil es laut deren internen Doku (die mit dem Datenblatt übereinstimmt) kein SPH gibt.
Wie gesagt,
bei der "falschen" INC wurde kein Hex-File erstellt.
Auch logisch, wenn der Assembler einen Fehler hat, bricht er ab.
Du könntest natürlich für die nun offensichtlich fehlerhafte Doku + Folgeschäden einen Bugreport bei Microchip machen. Die werden durchaus bearbeitet, habe ich in der Vergangenheit schon gemacht.
