Hat jemand diesen zum Laufen gebracht?
Irgendetwas scheint bei diesem Controller anders zu sein, aber in den
Datenblättern kann ich keinen Unterschied erkennen, und in den Errata
steht auch nichts.
an Gerhard H.:
Ich bin noch nicht weit gekommen, aber vorab eine Frage: in der
mprog-Schleife steht sleep, ich sehe aber nicht, wo SLPCTRL_CTRLA
gesetzt wird.
S. L. schrieb:> ich sehe aber nicht, wo SLPCTRL_CTRLA gesetzt wird.
Im Hauptprogramm soll hier nur Idle-geschlafen werden. Aber Du hast
Recht, dazu muss man SLEEP aktivieren. Hab ich vergessen, ist aber
bedeutungslos. Danke für den Hinweis.
Ich komme nicht weiter - dieses Programm lässt eine LED im
Sekundenrhythmus blinken, auf einem AVR128DA28, AVR32DD28, AVR16EB28,
ATmega4809, auch einigen 'tinyAVR® 1-series', aber nicht auf einem
AVR64EA28.
Vielleicht könnten Sie es ja bei sich ausprobieren, das wäre toll.
S. L. schrieb:
Ich habe das Ding noch nie benutzt, aber beim ersten Durchlesen des
entsprechenden Teils des DB (konkret: AVR128DA...) bin ich auf folgendes
gestoßen:
24.5.1
Initialization
To operate the PIT, follow these steps:
[...]
Note: The RTC peripheral is used internally during device start-up.
Always check the Synchronization Busy bits in
the RTC.STATUS and RTC.PITSTATUS registers, and on the initial
configuration.
Ich kann nicht erkennen, dass sich dein Code an irgendeiner Stelle um
diese Bits schert. Ich würde also in erster Näherung vermuten, dass er
auf den anderen Target nur zufällig entsprechend deiner Intention
verhält.
Okay, nächster Versuch - selbes Resultat.
Date-Code des verwendeten AVR64EA28: 2326URR
(und jetzt bin ich kurz davor, mit dem AVR16EB28 weiterzuarbeiten)
PS:
> Ich kann nicht erkennen, dass sich dein Code an> irgendeiner Stelle um diese Bits schert.
Also auch in den ersten Versionen wurde zumindest RTC_PITSTATUS geprüft.
S. L. schrieb:> Also auch in den ersten Versionen wurde zumindest RTC_PITSTATUS geprüft.
Um das Gerät einzuschalten muss der Netzstecker gesteckt werden und dann
der Netzschalter auf ON gestellt.
Also ich hab zumindest den Stecker gesteckt, Gerät geht aber nicht. ;)
Wenn 2 Bedingungen gefordert sind und du nach deiner Beschreibung nur
eine erfüllst, dann funktioniert es halt nicht.
S. L. schrieb:> wurde zumindest RTC_PITSTATUS geprüftOb S. schrieb:> Always check the Synchronization Busy bits in> the RTC.STATUS and RTC.PITSTATUS registers,
Ich habe nicht in den Sourcecode geschaut sondern nur deine Beschreibung
gelesen.
In deinem 2. Sourcecode im IRQ steht:
sbi IN_LED,LEDpit
Möchtest du eine LED einschalten? Mit dem "IN" Register? Ohne mich jetzt
mit der CPU näher beschäftigt zu haben erscheint mir das fehlerhaft.
an C-hater:
Übrigens finde ich diese 'Note' zwar im Datenblatt des ATmega4809, aber
weder in dem für AVR128DA28/32/48/64 noch im Preliminary für
AVR64EA28/32/48; also eine simple Suche nach 'during device'.
an 900ss:
Ihre Hilfsbereitschaft in allen Ehren, aber sie ist leider von keinerlei
Sachkenntnis getrübt. Zumal ich schrieb, dass das Programm auf den
anderen Typen läuft.
S. L. schrieb:> keinerlei Sachkenntnis getrübt.
Nee, ich hab auch keine Ahnung. Aber ich schrieb dass auch:
900ss schrieb:> Mit dem "IN" Register? Ohne mich jetzt mit der CPU näher beschäftigt zu> haben erscheint mir das fehlerhaft
an 900ss:
Das ist seit mindestens fünfzehn Jahren so bei den AVR8 - aber speziell
für Sie aus dem Preliminary Data Sheet AVR64EA28/32/48:
IN[7:0] Input Value
This bit field shows the state of the PORTx pins when the digital input
buffer is enabled.
Writing a ‘0’ to bit n in this bit field has no effect.
Writing a ‘1’ to bit n in this bit field will toggle the corresponding
bit in PORTx.OUT
Und jetzt sollten Sie sich heraushalten.
S. L. schrieb:> Das ist seit mindestens fünfzehn Jahren so bei den AVR8
Ich hab es jetzt auch nachgelesen.
Ich hab das so nie genutzt. Ich versuche den Code so zu schreiben dass
da steht was ich möchte. Wenn ich also einen Aushang setzen möchte, dann
nehmen ich das OUT Register, dafür ist es da. Dann bin ich später nicht
verwirrt und andere auch nicht. Alles andere ist für mich Unfug wenn es
keinen zwingenden Grund gibt das anders zu machen.
Und der freundlichen(?) Bitte, mich da raus zu halten, komme ich gerne
nach. Mein Code auf AVR funktioniert auch ;)
S. L. schrieb:> Ich armer Tor hingegen bin so klug als wie zuvor.
Bin leider gerade auf Reisen und kann da vorerst nix testen. Ich kann
auf die Schnelle keinen Fehler entdecken. Arbeitet (d)ein Programm denn
grundsätzlich auf dem EA- hast Du z.B. mal ne LED eingeschaltet? Hast Du
die aktuellsten Device-Packs? Wie schaun die Fuses aus - Stichwort
Watchdog? Und dann hast Du immer noch die Möglichkeit, für Dein Programm
noch mehr (für Deinen Test wesentliche) Teile meines Programms zu
übernehmen. Der PIT läuft, so einen Blinktest mach ich da auch gerne.
S. L. schrieb:> aber> weder in dem für AVR128DA28/32/48/64
Abschnitt 24.10 Synchonization
Ich soll mich zwar raushalten aber meine Mutter war auch schon immer
genervt :)
an Gerhard H.:
Vielen Dank für die Rückmeldung!
Fuses sind die ab Werk; Device-Pack ist aktuell.
Wenn ich das LED-toggeln in die main_loop setze, glimmt die LED, und
ich messe an ihr die entsprechende Frequenz.
Und eigentlich war ich der Meinung, ich hätte von Ihrem Programm alles
relevante übernommen bzw. gegengeprüft. Aber natürlich bleibt der
Sachverhalt, dass es bei Ihnen läuft und bei mir nicht.
an 900ss:
Schon richtig, hat aber erstens mit dem Fall hier nichts zu tun und ist
zweitens nicht das, was C-hater (alias Observer) schreibt ('... used
internally during device start-up').
S. L. schrieb:> Und eigentlich war ich der Meinung, ich hätte von Ihrem Programm alles> relevante übernommen bzw. gegengeprüft.
Ich war im von mir genutzten aktuellen Microchip Studio7 auch öfter der
Meinung alles relevante berücksichtigt zu haben. Dennoch gibts immer
wieder Phänomene mit Schreibweisen, die vllt. auf Studio/AVRASM-
Programmfehler deuten könnten.
Ich würde mal die gesamte Interrupttabelle und den Clock+RTC
Initialisierungsteil von mir komplett übernehmen. Die zentrale Frage
scheint ja wohl zu sein warum der Interrupt nicht auslöst. Sollte sich
der Teufel bis dahin nicht finden lassen helfe ich gern nächste Woche
intensiver.
Vermutlich ist es (wie meistens) eine Lappalie.
Erstmal ganz herzlichen Dank.
Ich werde mich (allerdings erst morgen) nochmals daransetzen und Ihrem
Tipp folgen, würde mich im Erfolgsfalle natürlich melden. Und notfalls
bleibt mir ja noch immer der Umstieg auf den AVR16EB28 - der läuft bei
mir.
900ss schrieb:> Wenn ich also einen Aushang setzen möchte, dann nehmen ich> das OUT Register,
Um ein Pin zu toggeln braucht man dazu eine IN, XOR, OUT Sequenz ... die
im Gegensatz zu einem SBI aber nicht atomar ist. Also noch IN SREG,
CLI, OUT SREG drumrun, mindestens aber CLI, SEI je nach Kontext.
Mit dem Laden der XOR Maske ist man dann bei mindestes 6 Instruktionen,
maximal 7 Instruktionen und 2 Register. Wer's braucht...
> Leider nur mit 1/4 Flash
In der geplanten Anwendung sind auch die 16 KiB mehr als üppig.
Und mit ca. 0.70 uA bei 3.0 V ist der EB brauchbar - eine
Aussage/Entscheidung, die ich eben bislang für den EA gar nicht treffen
kann, da bliebe nur das (blinde) Vertrauen in das 'Preliminary Data
Sheet'.
S. L. schrieb:> hat aber erstens mit dem Fall hier nichts zu tun
Ich hatte verstanden, dass dir der Abschnitt zur Synchronisation fehlt
im Datenblatt. Das wunderte mich und ich habe dann danach gesucht.
Johann L. schrieb:> Mit dem Laden der XOR Maske ist man dann bei mindestes 6 Instruktionen,> maximal 7 Instruktionen und 2 Register. Wer's braucht...
Stimmt schon, dann schreibe ich aber einen Kommentar dahinter oder nehme
einen anderen Namen um Leute, die das nicht wissen, nicht zu verwirren.
Man könnte dann auch das Register TOGGLE_LED nennen.... na ja
Ist auch kein Drama, das ist ja nicht der Fehler hier. Mich hat es nur
verwirrt.
Ich habe hier nur einen ATMEGA128DA48, auf dem der PIT IRQ läuft. Wenn
ich einen AVR64EA28 hier hätte, würde ich das jetzt probieren. Ich sehe
so erstmal auch keine Fehler. Aber ohne HW geht's halt nicht.
900ss schrieb:> Johann L. schrieb:>> Mit dem Laden der XOR Maske ist man dann bei mindestes 6 Instruktionen,>> maximal 7 Instruktionen und 2 Register. Wer's braucht...>> Stimmt schon, dann schreibe ich aber einen Kommentar dahinter oder nehme> einen anderen Namen
Geheimnis: Das geht auch mit SBI.
900ss schrieb:> Man könnte dann auch das Register TOGGLE_LED nennen
Das wäre schonmal eine saubere Lösung, die auch ein Leser versteht.
Ich muß zugeben, daß ich auch immer nur die klassische EXOR Methode
nehme. Die AVRs haben ja schon lange reichlich Flash, so daß die paar
eingesparten Bytes keine Rolle spielen.
an Gerhard Hauptmann:
Nochmals ganz herzlichen Dank für Ihre Unterstützung so weit.
Aber ich möchte jetzt einen Schlusspunkt setzen (möchte Sie auch nicht
weiter belästigen), der AVR16EB28 hat alles, was ich brauche, der EA
kommt in das Raritätenkabinett.
Ich hatte Ihren Rat von 20:34 mit Interrupttabelle und Initialisierung
befolgt - keine Änderung.
Ein Vergleich der Speicherabzüge von AVR64EA16 und ATmega4809 zeigt
keinen Unterschied, (natürlich) bis auf die Adressen.
Über Date-Code 2326URR und 'Silicon-Revision' B2 möchte ich jetzt
nicht weiter spekulieren, nur falls Sie das mit Ihrer Version
vergleichen möchten.
Leicht frustriert verabschiede ich mich, wünsche Ihnen eine angenehme
Heimkehr und ein schönes Wochenende.
S. L. schrieb:> an 900ss:> Schon richtig, hat aber erstens mit dem Fall hier nichts zu tun und ist> zweitens nicht das, was C-hater (alias Observer) schreibt ('... used> internally during device start-up').
Nicht wirklich ich schreib das, sondern Microchip. Ich hab's nur
copypasted. Ich hänge einfach mal die Quelle an, damit du dich davon
überzeugen kannst.
Seite 329, die letzten zwei Zeilen von genanntem Abschnitt 24.5.1.
S. L. schrieb:> Aber ich möchte jetzt einen Schlusspunkt setzen (möchte Sie auch nicht> weiter belästigen)
Keine Bange, mich interessiert aber nun trotzdem was da los ist.
Dankenswerterweise haben Sie den fraglichen Code hinterlassen.
Bei nächster Gelegenheit dann.
S. L. schrieb:> Dann laden Sie mal das aktuelle herunter:
Das habe ich natürlich auch. Aber wenn sich bei zwei Datenblättern zum
gleichen Thema etwas ändert und diese Änderung nicht dokumentiert ist,
dann sollte man vorsichtig sein. Der Fehler kann auch im neueren DB
liegen...
Ich habe ja auch nicht behauptet, dass das hier wirklich das Problem
ist, aber möglich schien es mir schon.
Das ist klar, hatte ich auch ausprobiert, aber mir ging es um den
sleep-Modus, bzw. um die Rückkehr aus diesem.
Heißt das, dass Sie mit einem AVR64EAn arbeiten?
S. L. schrieb:> ... mir ging es um den> sleep-Modus, bzw. um die Rückkehr aus diesem.
Sorry, das erfahre ich erst jetzt.
S. L. schrieb:> Heißt das, dass Sie mit einem AVR64EAn arbeiten?
Nein, war allgemein gemeint.
Okay, das hatte ich übersehen, war vielmehr gar nicht bis zu dieser
Stelle vorgedrungen auf Grund der Legende unter '1'.
Ändert aber nichts daran, dass bei meinem Controllerexemplar auf das
gesetzte RTC_PITINTFLAGS.PI nicht reagiert wird, auch ganz ohne sleep.
Georg M. schrieb:> dann kann man auf den PIT einfach verzichten
Nö, warum. Der gibt einen schönen zusätzlichen regelmäßigen
Timer-Interrupt ab.
Ich schau mir das heut abend genauer an.
S. L. schrieb:> Ändert aber nichts daran, dass bei meinem Controllerexemplar auf das> gesetzte RTC_PITINTFLAGS.PI nicht reagiert wird, auch ganz ohne sleep.
Eine Sache ist mir noch aufgefallen: MC zerlegt in der Beschreibung das
Setzen der Periode und des Enable-Bits in zwei Schritte (und impliziert
damit vermutlich auch eine zwischenzeitliche Abfrage bezüglich des
Sync-State).
Du hingegen schreibst in einem Rutsch beides und fragst erst hinterher
nach dem Sync-State.
an Observer:
Kann ich mir eigentlich nicht vorstellen, da a) das Programm auf allen
meinen anderen Typen läuft und b) der Teufel nicht an dieser Stelle zu
sitzen scheint: mein EB löst bei gesetztem PIT-Interruptflag einfach den
Interrupt nicht aus.
Ich werde Ihren Tipp aber heute noch umsetzen, und mich dann melden.
PS:
> Aber das Leben geht weiter.
Richtig. Mittlerweile bin ich beim AVR32DD28 und mit diesem
hochzufrieden.
PPS:
Der AVR64EA28 kommt in den Giftschrank.
S. L. schrieb:> Ich werde Ihren Tipp aber heute noch umsetzen, und mich dann melden.
Würde mich schon interessieren, der Aufwand hält sich ja sehr im Rahmen,
da du den Chip hast und das Programm auch nur minimal erweitert werden
muss, um auch noch diese letzte Sache zu testen.
> PPS:> Der AVR64EA28 kommt in den Giftschrank.
Wenn man jeden MC-Chip mit Siliziumfehlern in den Giftschrank stecken
will, hat man bald keine mehr...
an Observer:
LED blinkt z.B. auf einem AVR16EB28, blinkt nicht auf meinem AVR64EA28.
PS:
> MC-Chip mit Siliziumfehlern
Bei Gerhard H. scheint es zu funktionieren, nur bei mir nicht.
S. L. schrieb:> LED blinkt z.B. auf einem AVR16EB28, blinkt nicht auf meinem AVR64EA28.
Damit ist dann aus meiner Sicht ein nicht dokumentierter Bug im Silizium
bewiesen.
Meldest du sowas an MC?
Ich habe schon damals bei Atmel eher schlechte Erfahrungen beim
Bugreport gemacht. Die Scheiß-Inder haben recht regelmäßig nicht mal das
Problem begriffen, geschweige denn, dass sie sich die Mühe gemacht
hätten, die Sache mit dem (natürlich von mir gelieferten Code) zu
testen.
Konnten wohl nur C. Wenn überhaupt wenigstens das...
> ... Bug im Silizium bewiesen.
Erst noch abwarten, was Gerhard H. herausfindet.
> Meldest du sowas an MC?
Nö, egal wie es ausgeht.
Bis hierher war es wenigstens noch Übung und Erkenntnisgewinn, aber
damit reicht es dann auch. Melden soll das ein Großkunde, der
gegebenenfalls auch Druck machen kann.
S. L. schrieb:> Erst noch abwarten, was Gerhard H. herausfindet.
Der hat herausgefunden daß Dein Code (im Anhang) erwartungsgemäß
funktioniert und die LED (auf PA6 abgeändert, mein Testboard) fröhlich
blinkt. Welches Device-Pack ist denn in Deiner Solution eingestellt? Ich
habe hier die AVR-Ex DFP Version 2.8.189. Von einem Hardware-Fehler in
Deiner Testschaltung abgesehen kann ich mir eigentlich nur noch eine
fehlerhafte Definition in einem anderen, von Dir verwendeten Device-Pack
vorstellen.
Wofür sind eigentlich Deine Controller-Includes? Die werden im Studio
einfach in der Solution eingestellt und gut ist. Gleichfalls überflüssig
ist .org 0. Für EA - Interruptvektoren der Hinweis, daß hier JMP statt
RJMP fällig ist.
Hat aber jetzt alles nix mit Deinem "Problem" zu tun ...
Mit dem aktuellen Studio 7.0.2594 arbeitest Du doch?
Womit programmierst Du?
Gerhard H. schrieb:> Der hat herausgefunden daß Dein Code (im Anhang) erwartungsgemäß> funktioniert und die LED fröhlich blinkt.
Das wird dann wirklich endgültig spannend. Da bleibt ja nur noch
Vergleich der Silizium-Revision.
Es ist jedenfalls sehr, sehr unwahrscheinlich, dass S.L. ein einzelnes
Exemplar mit einem derart spezifischen Fehler erwischt hat.
> Welches Device-Pack ist denn> in Deiner Solution eingestellt?
Das ist wohl ziemlich irrelevant. Die paar verwendeten Bits und
Registeradressen sind definitiv immer gleich geblieben, seitdem das
Dingens überhaupt in den Packs aufgetaucht ist.
Sprich: hier kann das Problem unmöglich liegen.
> Wofür sind eigentlich Deine Controller-Includes? Die werden im Studio> einfach in der Solution eingestellt und gut ist.
Ja, hier könnte es tatsächlich ein Problem geben. Wenn man explizit
eigene Device-Header included und implizit die nutzt, die man über die
IDE konfiguriert, dann kann es knallen. Das sollte dann allerdings schon
beim Assembler-Lauf knallen. Ich traue S.L. absolut zu, diesen Knall
hören zu können...
> Gleichfalls überflüssig> ist .org 0.
Überflüssig vielleicht, aber sicher nicht störend oder gar ein Problem.
> Für EA - Interruptvektoren der Hinweis, daß hier JMP statt> RJMP fällig ist.
Das ist definitiv Unsinn. So lange sich die ISRs im Nahbereich der
Vektortabelle rumtreiben, kann man sie natürlich per rjump aus der
Vektortabelle anspringen. Bei der doch sehr überschaubaren Menge an
Code ist das ganz sicher gegeben...
> Device-Pack
Atmel.AVR-Ex_DFP.2.9.197: AVR64EA28def.inc Created: 2024-02-29 14:26
Sollte keine Rolle spielen, laut Speicherabzug stimmen die
Flash-Adressen mit dem Datenblatt überein, die Peripherie-Adressen z.B.
sind dieselben wie beim ATmega4809.
> Hardware-Fehler in Deiner Testschaltung
Ich stecke nur AVR64EA28 und AVR16EB28 um
> Wofür sind eigentlich ...
Ich arbeite mit einem uralten AVR-Studio 4. Wie aus dem Speicherabzug
von '03.05.2024 12:33' zu ersehen ist, spielt das keine Rolle.
> JMP statt RJMP
Spielt auch keine Rolle.
Welchen Date-Code hat Ihr AVR64EA28? Meiner hat '2326URR', auf der
Unterseite steht THAILAND und P3 - was auch immer das heißen mag.
Können Sie mir einen Speicherabzug geben?
... wenn es Ihnen die Mühe wert ist, ich selbst bin, wie bereits
geschrieben, mittlerweile auf einen AVR32DD28 umgestiegen.
PS:
AVRASM: AVR macro assembler 2.2.8 (build 80 Jan 14 2020 18:27:50)
PPS:
korrigiere: 'P5'
avrea28.jpg von 18:42 (18:56):
'EEPROM size 1 KB' - well now, how about that? - im Datenblatt
steht 512 Bytes, und im AVR64EA28def.inc '#define EEPROM_SIZE 0x0200'.
Aber das nur am Rande.
Ob S. schrieb:> Sprich: hier kann das Problem unmöglich liegen.
Da wär ich mir nicht so sicher.
Allerdings ist die verwendete DP Version noch neuer als meine.
Da wird sich doch kein Fehler eingeschlichen haben ...
P.S. hat sich nicht, habe gerade selber geupdatet- funktioniert.
S. L. schrieb:> Ich arbeite mit einem uralten AVR-Studio 4
Na ja. Programmieren Sie dann etwa mit AVRDUDE?
Das alte Studio unterstützt doch kein modernes Microchip-Tool.
Ich verwende AtmelICE oder nEDBG.
Ob S. schrieb:> aber sicher nicht störend oder gar ein Problem.
Hat auch niemand behauptet.
S. L. schrieb:> Welchen Date-Code hat Ihr AVR64EA28? Meiner hat '2326URR'
Meiner 223760D. Ebenso älter.
S. L. schrieb:> Können Sie mir einen Speicherabzug geben?
Alles was im DEBUG Verzeichnis zu finden ist gerne- siehe Anhang.
Die LED Position hab ich vorm Assemblieren wieder auf 7 geändert.
Ob S. schrieb:> Das ist definitiv Unsinn. So lange sich die ISRs im Nahbereich der> Vektortabelle rumtreiben, kann man sie natürlich per rjump aus der> Vektortabelle anspringen. Bei der doch sehr überschaubaren Menge an> Code ist das ganz sicher gegeben...
Nun, da es selten bei Minicode bleibt und man für gewöhnlich mehrere
Interrupts verwendet wird aus dem "definitiven Unsinn" ganz schnell
bittere Notwendigkeit. Es sei denn, Du willst der Interrupttabelle
unnützerweise noch zusätzliche Platzhalter einfügen...
So, für mich ist der Fall gegessen.
Aus dem "Giftschrank" kann das Teil definitiv wieder raus :)
Zwar kein Speicherabzug, aber die Intel-Hex-Datei ist genausogut: wenn
ich Ihr EATEST.hex in den AVR16EB28 flashe, blinkt die LED, bei meinem
AVR64EA28 blinkt sie nicht.
Vielleicht sollte ich es mal mit Voodoo versuchen, ein Säckchen mit
Knochen über dem Teil schwenken, dunkle Sprüche murmeln, ein Tier opfern
...
PS:
> Aus dem "Giftschrank" kann das Teil definitiv wieder raus
Au contraire - mein Exemplar bleibt definitiv drin.
Ob S. schrieb:> Das wird dann wirklich endgültig spannend. Da bleibt ja nur noch> Vergleich der Silizium-Revision.
@Gerhard H.:
Man kann die HW-Revision auslesen, man braucht dazu nichtmal irgendwas
zu programmieren, nur den Debugger zu benutzen. Könntest du das
vielleicht mal tun? Screenshot reicht.
@S.L.:
Du kannst das allerdings leider nicht so einfach tun, da du dich aus
unerfindlichen Gründen auf das uralte Studio4 beschränkst und deswegen
vermutlich auch nicht die dazu nötige Hardware hast. Aber auch du
könntest das auslesen. Musst dazu allerdings etwas programmieren. Kannst
du, da bin ich sicher.
S. L. schrieb:> bei meinem> AVR64EA28 blinkt sie nicht
Cool. PA7 etwa kaputt?
Ob S. schrieb:> Man kann die HW-Revision auslesen, man braucht dazu nichtmal irgendwas> zu programmieren, nur den Debugger zu benutzen.
Das tat ich bereits.
Wenn Du mal Deinen geschätzten Blick weiter hoch bemühen würdest...
> PA7 etwa kaputt?
Nee, wie vor einer gefühlten Ewigkeit geschrieben:
> Wenn ich das LED-toggeln in die main_loop setze, glimmt die LED,> und ich messe an ihr die entsprechende Frequenz.> HW-Revision auslesen ... allerdings etwas programmieren
Hatte ich vor langer Zeit mal gemacht, wie ging das nochmal ...?
S. L. schrieb:> Hatte ich vor langer Zeit mal gemacht, wie ging das nochmal ...?
Tools/Device Programming/Device information.
Naja, mit Studio7 halt...
Ich würde fast wetten bei mir funktioniert Ihr Controller :)
> Ich würde fast wetten bei mir funktioniert Ihr Controller
Wohnen Sie in Radel-Distanz von Freiburg i.Brsg.? Kennen doch sicher ein
nettes Cafe ...
an Observer:
Ist das der 'System Information Block'?
Gerhard H. schrieb:> Nun, da es selten bei Minicode bleibt und man für gewöhnlich mehrere> Interrupts verwendet wird aus dem "definitiven Unsinn" ganz schnell> bittere Notwendigkeit.
Nö. ISRs sind typisch kurz bis sehr kurz. Und natürlich kann man diese
kurzen Codefragmente ganz bewußt nahe an der Vektortabelle lokalisieren.
Mein Gott, das ist ja nichtmal in C irgendwie problematisch (macht der
Compiler von sich aus schon so...).
> Es sei denn, Du willst der Interrupttabelle> unnützerweise noch zusätzliche Platzhalter einfügen...
Du kannst definitiv nicht wirklich Assembler.
Was für Platzhalter? Solange du jeden benutzten Vector mit dem passenden
.org einleitest, brauchst du überhaupt keine "Platzhalter". Die ggf.
zwei ungenutzen Byte eines Vektors bleiben halt einfach 0xff. Tut keinem
weh und tut der Funktion keinerlei Abbruch.
Tss...
Ob S. schrieb:> Nö. ISRs sind typisch kurz bis sehr kurz. Und natürlich kann man diese> kurzen Codefragmente ganz bewußt nahe an der Vektortabelle lokalisieren.
Erzähl mir doch nicht was ISRs typischerweise sind.
Die sind so lang wie ich sie mache- und mit JMP ortsunabhängig
angesprungen.
> Was für Platzhalter? Solange du jeden benutzten Vector mit dem passenden> .org einleitest
Toll. Mindestens genauso überflüssig.
Eine ordentliche, vollständige JMP Tabelle und gut ist.
Mit RJMP fällst Du dann auf die Schnauze.
Tss..
Gerhard H. schrieb:> Mit RJMP fällst Du dann auf die Schnauze.
Ist mir noch nie passiert. Warum auch? Die Logik der Sache sagt: es gibt
keinen Grund, ISRs irgendwo weitab der Vektortabelle zu lokalisieren.
Und sie sagt auch: es gibt keinen Grund, nahe Ziele nicht per rjmp
anzuspringen. Dazu gibt's die Instruktion ja schließlich.
Ob S. schrieb:> Gerhard H. schrieb:>>> Mit RJMP fällst Du dann auf die Schnauze.>> Ist mir noch nie passiert. Warum auch? Die Logik der Sache sagt: es gibt> keinen Grund, ISRs irgendwo weitab der Vektortabelle zu lokalisieren.> Und sie sagt auch: es gibt keinen Grund, nahe Ziele nicht per rjmp> anzuspringen. Dazu gibt's die Instruktion ja schließlich.
Ach so, fast vergessen: wenn es doch mal nötig ist, eine ISR fernab der
Vektortabelle zu plazieren, dann meckert sehr zuverlässig der Assembler,
wenn man in der Vektortabelle ein rjmp benutzt hat, der das Ziel nicht
erreichen kann.
Also ich sehe hier absolut kein Problem.
Ob S. schrieb:> Die Logik der Sache
Welche Logik?
Eine komplette Interruptvektortabelle dient Ordnung, Übersicht,
Codewiederverwendbarkeit und Sicherheit: Irrtümlich aktivierte
Interrupts werden nämlich sicher abgefangen. Das ist den einen JMP Takt
mehr locker wert, und den Flash-Mehraufwand auch.
Wenn Du Deine Befriedigung statt dessen in der Totaloptimierung findest
meinetwegen- nur solltest Du deshalb andere Wege nicht so
abqualifizieren.
S. L. schrieb:> C-hater, könnten wir bitte zum eigentlichen Problem zurückkehren?
Das würde ich auch vorschlagen.
Schade daß wir nicht die gleiche moderne Tool-Basis verwenden.
an Gerhard Hauptmann:
Observer hat sich wieder in den alten C-hater zurückverwandelt (a la
'Dr. Jekyll und Mr. Hyde'), und vergiftet wie in alten Zeiten jede
Diskussion.
Von Ihnen verabschiede ich mich aufs freundlichste, für alle anderen bin
ich jetzt einfach weg.
Auch wenn S.L. es nicht interessiert...
Evtl. die Startup time mit den Fußes auf maximum setzen? Er weiß,
manchmal ist es sowas "einfaches". Vielleicht ist der Aufbau mit
dieserlm Controller etwas sensibler als bei den anderen Controllern.
Nachtrag: oder BOD einschalten?
900ss schrieb:> Evtl. die Startup time mit den Fußes auf maximum setzen?
Hat keinen Einfluß. Da bin ich alles durchgegangen.
> Vielleicht ist der Aufbau mit> dieserlm Controller etwas sensibler als bei den anderen Controllern.
In keinster Weise.
> BOD einschalten?
braucht man auch nicht.
Vorab: An den, den es angeht: Sie mögen fachlich noch so kompetent sein,
lieber bleibe ich für den (spärlichen) Rest meines Lebens unwissend, als
noch einmal mit so etwas kleinkariertem, engstirnigem, kurz: borniertem
zu diskutieren, ja nur zu kommunizieren; ich habe es, weiß Gott, in den
letzten anderthalb Jahrzehnten immer mal wieder versucht. In Ihr
Stammbuch: "charakterlich ungeeignet zur Teamarbeit".
---------------------------
Ich bin dies vielleicht dem einen oder anderen hier schuldig (sowie DEM
einen stillen Mitleser) - nie hätte ich gedacht, das so etwas einmal an
mich kommen könnte (es gibt immer ein erstes Mal), nach einem
Vierteljahrhundert mit den AVR8: mein AVR64EA28 (und ich habe nur den
einen) scheint generell keine Interrupts auszulösen. Wer Zeit übrig hat
und sie vergeuden will, möge alles weitere aus dem beigefügten Programm
ersehen. Ich bezog den Controller, zusammen mit einigen anderen der
AVRmxyn-Reihe, am 25. April von einem großen deutschen Versender; den
Namen nenne ich nicht, weil er höchstwahrscheinlich gar nichts dafür
kann - wer regelmäßig dort bestellt und mit den AVR8 arbeitet, wird
anhand des Datums sofort erkennen, um wen es sich handelt, die anderen
brauchen es nicht zu wissen.
S. L. schrieb:> mein AVR64EA28 (und ich habe nur den> einen) scheint generell keine Interrupts auszulösen.
Diese Codezeilen verstehe ich nicht:
1
lds tmpi,TCA0_SINGLE_INTFLAGS
2
sts TCA0_SINGLE_INTFLAGS,tmpi
3
...
4
lds tmpi,TCB0_INTFLAGS
5
sts TCB0_INTFLAGS,tmpi
Du schreibst die Adresse des Interruptflagregisters in genau dieses.
Sollte dort nicht die Bitmaske des Interruptflags geschrieben werden?
Grüßle,
Volker
P.S.: Ich weis schon, warum ich lieber in C programmiere. :-)
Mich lässt das ratlos zurück. Fakt ist nur, an der Software liegts nicht
und am EA-Controllertyp an sich auch nicht. Beides funktioniert ganz
unauffällig und wie erwartet. Meine Fantasie lässt nur noch irgend eine
Art Programmierfehler zu, obwohl Sie das Programm bestimmt ordentlich
zurückgelesen und verglichen haben. Irgend einen serienmäßigen
Hardwarefehler kann doch niemand annehmen wenn Ihr Controller sogar
neuer als meiner ist. Auffällig ist allerdings das etwas
unterschiedliche Format des Date-Codes. Die IC Unterseite bin ich Ihnen
noch schuldig: Thailand 05 (oder O5).
Idealerweise sollten Sie nochmal mit einem zweiten Exemplar aus anderer
Quelle gegenprüfen. Da mich das ungewöhnliche Thema interessiert gerne
unentgeldlich von mir.
Volker B. schrieb:> Du schreibst die Adresse des Interruptflagregisters in genau dieses.
Nein, er schreibt den Inhalt dieses in selbiges zurück. Das quittiert in
dem speziellen Fall genauso den Interrupt (und definitiv alle
anstehenden in diesem Register).
Gerhard H. schrieb:> Volker B. schrieb:>> Du schreibst die Adresse des Interruptflagregisters in genau dieses.>> Nein, er schreibt den Inhalt dieses in selbiges zurück. Das quittiert in> dem speziellen Fall genauso den Interrupt (und definitiv alle> anstehenden in diesem Register).
OK, danke! Meine Assemblerkenntnisse sind etwas eingerostet. :-)
Grüßle,
Volker
> serienmäßigen Hardwarefehler
Ich denke eher an einen singulären Produktionsfehler, Staubkorn oder
ähnliches. Warum das in der Endkontrolle nicht aufgefallen ist ...?
an Volker B.:
'This bit is set when an overflow interrupt occurs ... The bit is
cleared by writing a ‘1’ to the bit position'
Gerhard H. schrieb:>> BOD einschalten?>> braucht man auch nicht.
Das ist sicher etwas zu "allgemein". Aus Langeweile ist die BOD nicht
eingebaut worden. Dass es in deiner Umgebung so funktioniert, will ich
glauben. Aber bei S.L. mag es anders sein. Er nutzt ein anderes Netzteil
als du u.s.w. Auch wenn die anderen Controller bei ihm ohne BOD laufen
heißt das nicht, dass es der AVR64EA28 auch macht.
Eingeschaltet tut es nicht schaden sondern sorgt für ein geregeltes
Startup (Reset) wenn die Spannung z.B. zu langsam hochläuft. Gibts
alles.
Und das ist wirklich recht einfach ausprobiert.
Ich glaube kaum an einen Defekt des Controllers. Es ist ein anderer
fieser versteckter Fehlerteufel. Und mich würde es auch fuxen :) Ich hab
mir schon extra einen AVR64EA28 mitbestellt um das nachzuvollziehen.
Scheint aber sinnlos, da es kein Controller "typisches" Verhalten ist.
Na ja, hat die Familie Zuwachs bekommen ;)
900ss schrieb:> Aus Langeweile ist die BOD nicht eingebaut worden
Natürlich nicht.
Wenn S.L. aber nur den Chip in ein und derselben Testschaltung wechselt
und es mit einem funktioniert und dem anderen nicht dürfte eine
fehlerhafte Stromversorgung wohl kaum infrage kommen. Die Erfahrung
würde ich ihm schon zutrauen. Und glaub mir, mein eigener Aufbau ist zu
diesem Test alles andere als professionell. Daß sich just ein EA so
zickig im Vergleich zu den vielen anderen verhielte die man so alles
verwendet- nö.
AVRs sind gutmütige und robuste Arbeitstiere.
Anlaufen tut der EA bei S.L. ja zweifellos.
Daß dann trotzdem das Interruptsystem außer Gefecht bliebe -
abenteuerlich.
> Ich glaube kaum an einen Defekt des Controllers
Ich auch nicht. Das berüchtigte Staubkorn wär wirklich ein dolles Ding.
Mehr lohnt es sich ohne mehr Information zu Aufbau, Programmierung und
IC-Herkunft aber hier nicht zu spekulieren.
> Ich hab mir schon extra einen AVR64EA28 mitbestellt um das> nachzuvollziehen
Prima. Dann wären wir schon zu dritt im Forum mit AVR-EA Erfahrung. Sei
aber nicht enttäuscht wenn Du nur zum gleichen Ergebnis wie ich kommst
:)
Gerhard H. schrieb:> Wenn S.L. aber nur den Chip in ein und derselben Testschaltung wechselt> und es mit einem funktioniert und dem anderen nicht dürfte eine> fehlerhafte Stromversorgung wohl kaum infrage kommen.
Was ich nicht getestet habe, weiß ich nicht. Meine Erfahrung mit der ich
gut gefahren bin. Wenn nix mehr hilft sollte man die
Selbstverständlichkeiten in Frage stellen.
Gerhard H. schrieb:> Die Erfahrung> würde ich ihm schon zutrauen.
Ich habe keine Zweifel an der Erfahrung von S.L. was leider nicht auf
Gegenseitigkeit beruht ;)
Gerhard H. schrieb:> Sei> aber nicht enttäuscht wenn Du nur zum gleichen Ergebnis wie ich kommst> :)
Bin ich jetzt schon :) Ich vermute ganz stark, dass ich das gleiche
sehe, wie du auch.
Gerhard H. schrieb:> Daß dann trotzdem das Interruptsystem außer Gefecht bliebe -> abenteuerlich.
Zugegeben, ja. Aber...
900ss schrieb:> sollte man die> Selbstverständlichkeiten in Frage stellen
Vielleicht ist der Abblock-Kondensator grenzwertig.
Am ehesten würde ich nach allem hier auf eine Fälschung tippen.
Vorausgesetzt die Programmierung mit überaltertem Studio +
unbekanntem Programmier-Adapter gelang.
S.L. könnte mal ein gutes Foto seines Exemplars zum Vergleich zeigen.
Meine Quelle war microchipdirect. Die ist über Zweifel erhaben.
900ss schrieb:> Ich hab mir schon extra einen AVR64EA28 mitbestellt um das nachzuvollziehen.
Ich glaub ich bestell jetzt auch einen :-)
Das kann doch net sein, dass das net tut - laut Datenblatt und diversen
C Sourcen sollte das kein Hexenwerk sein.
@900ss
In welchem Gehäuse hast du den bestellt, oder ist es ein fertiges Board?
Adam P. schrieb:> Das kann doch net sein, dass das net tut
Bei Gerhard funktioniert es ja. Es wird wohl ein Problem bei S.L. sein.
Was auch immer.
Adam P. schrieb:> In welchem Gehäuse hast du den bestellt, oder ist es ein fertiges Board?
Ich habe einen einzelnen Controller im DIL Gehäuse gekauft.
Kommt aber wahrscheinlich erst zum Wochenende. Ich hatte einen sehr
lange Liste zu bestellen und leider ist nicht alles lieferbar. :(
Hallo,
ich habe heute festgestellt das mein AVR64EA32 im FQFP 4 Probleme hat.
Weder der RTC- noch der PIT ISR Interrupt funktionieren. Meine Led an
PA3 blinkt nur wenn ich das Interrupt Flag in der Hauptschleife
auswerte.
Das 3./4. Problem betrifft die Zuweisungen der Bits ins RTC.CTRLA bzw.
RTC.PITCTRLA Register. Verodern direkt mit Register funktioniert bei mir
nicht. Ich muss wie beim Errata des ATmega4809 alle Bits in einer temp
Variablen verodern und diese "Summe" dann dem Register mit einer
Zuweisung geben. Ich sehe aktuell keine andere Lösung.
Veit D. schrieb:> Weder der RTC- noch der PIT ISR Interrupt funktionieren.
Bemerkenswert.
Das spitzt sich zum Krimi zu.
Da kann man nur möglichst viele dazu aufrufen es ebenfalls zu testen.
Vielleicht kristallisiert sich sich ja so der eigentliche Hintergrund
heraus.
Ach du Sch...
Okay mit sei() funktioniert es. Vielen Dank an das wachsame Auge. ;-)
Das Problem mit den Registerzuweisungen bleibt bestehen. Wie beim
ATmega4809.
Hallo,
habe mir einmal sein Assembler angeschaut. Wenn S.L. diese beiden
Zuweisungen zusammenfasst, sollte es auch bei ihm blinken.
[code]
; 3. Select the period for the interrupt by writing the desired value to
the Period (PERIOD) bit field in the Periodic Interrupt Timer Control A
(RTC.PITCTRLA) register.
rtcstatus
ldi tmp0,0b0_1101_00_0 ; /16384
sts RTC_PITCTRLA,tmp0
; 4. Enable the PIT by writing a ‘1’ to the Periodic Interrupt Timer
Enable (PITEN) bit in the RTC.PITCTRLA register.
rtcstatus
lds tmp0,RTC_PITCTRLA
ori tmp0,0b0_0000_00_1 ; enable
sts RTC_PITCTRLA,tmp0
[code]
Veit D. schrieb:> Verodern direkt mit Register funktioniert bei mir> nicht.
Wozu? Mit einem AVR I/O Register kann man nix direkt verodern.
> Wenn S.L. diese beiden> Zuweisungen zusammenfasst
Welche beiden Zuweisungen?
RTC_PITCTRLA wird genau einmal geladen und gut ist.
> sollte es auch bei ihm blinken
Fakt ist, sein Code (Anhang) blinkt bei ihm nicht und bei mir schon.
Gerhard H. schrieb:> Das spitzt sich zum Krimi zu.Veit D. schrieb:> Okay mit sei() funktioniert es.
Schade.
Jetzt ist die Spannung schon wieder raus :)
Hallo,
ich sehe 2 Registerzuweisungen im Assembler. Oder etwa nicht.
Einmal wird der CycleCount geschrieben und danach kommt das Enable Bit
dazu.
Sind für mich 2 Schreibzugriffe?
Er müßte gleich
Gerhard H. schrieb:> Veit D. schrieb:>> zusammen zuweisen>> Na das tut er doch. Siehe sein Code.> RTC_PITINTCTRL und RTC_PITCTRLA sind verschiedene Register...
Das von 21:00 Uhr habe ich aus seinem letzten Code zum Thema 06.05.2024
16:49.
2x RTC_PITCTRLA so wie ich es zitiert habe.
Gerhard H. schrieb:> Veit D. schrieb:>> Das hier funktioniert nicht>> Könnte das ein Problem des Compilers sein? Sorry, ich mach nur Asm. Da> gibts kein solches Problem.
Da bin ich mir ganz sicher, dass der Compiler das richtig macht. Sonst
hätte ich überall Problem mit verodern. Zudem ich das kannte aus dem
Errata vom ATmega4809 und habs auch hier ausprobiert.
S.L. soll das einfach ausprobieren und Statusmeldung abgeben. :-)
Veit D. schrieb:> Das von 21:00 Uhr habe ich aus seinem letzten Code
OK, den hab ich mir gar nicht angeschaut aber das war auch nicht nötig
da sein Problem ja bereits in seinem kürzesten Code (mein Anhang)
besteht... D.h. eine bestimmte OR Formulierung kann nicht ursächliches
Problem sein. Man muß es jetzt nicht komplizierter machen als nötig.
> S.L. soll das einfach ausprobieren und Statusmeldung abgeben. :-)
Soll er. Aber ich glaube er ist über alle Berge :)
an Veit Devil:
> Er müßte gleich ... 0b0_1101_00_1 ... zusammen zuweisen.> Statusmeldung abgeben
So hatte ich es ursprünglich (und mache es immer so), dieses
Auseinanderziehen erfolgte auf Anraten C-haters - brachte aber keinerlei
Änderung.
Wie schon geschrieben, löst mein (einziger) AVR64EA28 keinen PIT-,
TCA- oder TCB-Interrupt aus, also vermutlich überhaupt keinen. Und bevor
sich da nicht von anderer Seite grundlegend neue Erkenntnisse ergeben,
investiere ich nicht noch mehr Zeit.
> Aber ich glaube er ist über alle Berge :)
In der Tat: nachher geht's über die Wilhelmshöhe!
> Das hier funktioniert nicht - bei diesem Controller !> ... RTC.CTRLA |= ...
Das kann an den fehlenden zwischengeschobenen Status-Abfragen liegen,
siehe im Datenblatt '24.10 Synchronization': "it will take some RTC
and/or peripheral clock cycles before an updated register value is
available". Siehe auch mein (von C-hater gewünschtes) Programm von
06.05.2024 16:49:
Beitrag "Re: AVR64EA28: PIT-Interrupt"
PS:
Erläuterung:
Für das 'RTC.CTRLA |=' muss es ja zuerst gelesen werden, zu diesem
Zeitpunkt ist es aber noch gar nicht aktualisiert worden mit dem im
vorherigen Befehl geschriebenen Wert.
PPS:
Und weil heute Feiertag ist, noch ein nettes Cartoon dazu.
S. L. schrieb:>> Das hier funktioniert nicht - bei diesem Controller !>> ... RTC.CTRLA |= ...>> Das kann an den fehlenden zwischengeschobenen Status-Abfragen liegen,> siehe im Datenblatt '24.10 Synchronization': "it will take some RTC> and/or peripheral clock cycles before an updated register value is> available". Siehe auch mein (von C-hater gewünschtes) Programm von> 06.05.2024 16:49:> Beitrag "Re: AVR64EA28: PIT-Interrupt">> PS:> Erläuterung:> Für das 'RTC.CTRLA |=' muss es ja zuerst gelesen werden, zu diesem> Zeitpunkt ist es aber noch gar nicht aktualisiert worden mit dem im> vorherigen Befehl geschriebenen Wert.
Kann ich bestätigen, funktioniert.
Gerhard H. schrieb:> Wozu? Mit einem AVR I/O Register kann man nix direkt verodern.
Das ist nicht ganz richtig. Zumindest Die IO-Register mit den Adressen
0..0x1f im IO-Space kann man zumindest mit einzelnen immediate Bits
verodern. Siehe Asm-Instruktion "sbi".
Spielt aber beim vorliegenden Problem keine Geige, da die hier
relevanten Register halt nicht in diesem Bereich liegen.
> Fakt ist, sein Code (Anhang) blinkt bei ihm nicht und bei mir schon.
Genau. Das ist der springende Punkt. Inzwischen (ich war 'ne Weile weg)
hat S.L. ja auch noch herausgefunden, dass auch die Interrupts von TCA
und TCB bei seinem Exemplar nicht funktionieren.
Also entweder hat er da schlicht ein defektes Exemplar erworben oder es
ist an irgendwas "teilgestorben" oder es war ein Fake oder es gab eine
sehr frühe Silizium-Revision mit noch schwereren Bugs als bei MC sowieso
üblich.
Fake würde ich mal ausschließen, das lohnt nicht. Die EA haben irgendwie
kein besonderes Feature, was sie von DA, DB oder DD nennenswert abheben
würde. Zumindest kann ich keins erkennen, mag aber sein, dass ich
irgendwas überlesen habe. Warum sollten ausgerechnet dafür Fakes
produziert werden? Das lohnt doch sicher nicht.
Diese Revisionsgeschichte könnte man nur abklären, wenn entweder S.L.
einen aktuellen Debug-Adapter kaufen würde und Studio7 oder MPLABX
installieren würde oder halt dadurch, dass er selber das UPDI-Protokoll
implementiert, um an den System Information Block heranzukommen.
Ersteres kostet leider etliches Geld, letzteres etliche Zeit. Ich habe
volles Verständnis dafür, dass ihm der Einsatz eines EA das nicht Wert
ist. So besonders ist der halt nicht, dass man ihn unbedingt verwenden
wollen würde oder gar müsste.
Ob S. schrieb:> Das ist nicht ganz richtig. Zumindest Die IO-Register mit den Adressen> 0..0x1f im IO-Space kann man zumindest mit einzelnen immediate Bits> verodern.
OR iginelle Interpretation. Zumindest nicht ganz falsch :)
> oder es gab eine> sehr frühe Silizium-Revision
Dazu passt der neuere Date-Code nicht.
> Die EA haben irgendwie> kein besonderes Feature
Im ADC Teil gibts durchaus nette Neuigkeiten.
Speziell dafür Fakes lohnen natürlich nicht.
> mit noch schwereren Bugs als bei MC sowieso> üblich
Die EA zeigen sich in den Errata eigentlich bereits recht zivilisiert.
> einen aktuellen Debug-Adapter kaufen würde und Studio7
kann ich auch nur empfehlen. Z.B. nEDBG auf einem entsprechenden
Curiosity Nano Modul. Naheliegenderweise gleich
https://www.microchip.com/en-us/development-tool/ev66e56a
Kostet nicht die Welt. Der Kauf zur Debug-Verwendung unter Linux würde
dann aber meines Wissens die Installation von MPLAB-X erfordern (rein
programmiert ist das Teil auch via virtuellem USB-Laufwerk, da wird
einfach die .hex reingezogen).
Mitsamt aktueller IDE wäre es dann ein Leichtes, an die interessanten
Hardware-Daten heranzukommen. Ob die dann aber irgendeinen Aufschluss
für diesen Fall liefern ist eine andere Frage.
Auf jeden Fall würd ich mir das Exemplar gut aufheben.
Sowas hat immer einen ganz besonderen Wert.
Schade daß es weiter kein Foto und nähere Infos zum Programmiertool
gibt. Ungelöste Phänomene wie dieses dürften weiter Interesse
garantieren.
Gerhard H. schrieb:> Schade daß es weiter kein Foto und nähere Infos zum Programmiertool> gibt.
Er hat ja gesagt, dass er das Studio4 verwendet. Aus dem Studio4 selber
kommt nur UPDI via STK500v2-Wrapper in Frage. Wenn er zusätzlich zum
Studio4 auch noch avrdude benutzt, werden die Möglichkeiten auch nicht
sehr viel größer, da könnte man höchsten den Umweg über STK500v2
einsparen.
Die eigentliche Programmierhardware dürfte in jedem Fall ein (minimal
umgebauter) handelsüblicher USB-Seriell-Wandler mit CMOS-Pegeln sein.
an Gerhard Hauptmann:
> nähere Infos zum Programmiertool
Zwar verstehe ich nicht ganz, welche Rolle das spielt, wenn das aus dem
Programmspeicher zurückgelesene Programm (bis auf die Sprungadressen)
mit dem anderer Controllertypen übereinstimmt
(Beitrag "Re: AVR64EA28: PIT-Interrupt"), aber bitte:
'Programmiertool' ist ein Selbstbau-Programmiergerät, basierend auf dem
AVR128DA28, welches über ein PC-Hyperterminal Befehle und eben die
Intel-Hex-Dateien empfängt; und mit dem ich z.B. auch den 'System
Information Block' auslese
(Beitrag "Re: AVR64EA28: PIT-Interrupt");
den Vergleich mit den Werten, die Ihre IDE liefert
(Beitrag "Re: AVR64EA28: PIT-Interrupt")
überlasse ich Ihnen.
Übrigens musste ich deshalb auch nicht nachfragen, ob microchip.direct
unprogrammierbare AVR16EB28 verkauft, weil ich für eben diese meine
Firmware die SIGROW-Adresse auch bei 0x1080 (für die AVRmEBn, statt bei
0x1100 wie für alle anderen) suchen lassen musste
(Beitrag "Re: Verkauft microchipdirect unprogrammierbare AVR16EB28?").
PS:
Wenn Sie weiterhin mit C-hater diskutieren möchten, so ist das Ihr
Vergnügen, meines nicht.
S. L. schrieb:> 'Programmiertool' ist ein Selbstbau-Programmiergerät, basierend auf dem> AVR128DA28
Wo genau hast du das das erste Mal erwähnt? Wenn mich nicht alles
täuscht: Genau erst hier!
Und übrigens: die SIGROW ist NICHT identisch mit dem ausschließlich
über UPDI auslesbaren Device Information Block.
Aber wenn du schon ein eigenes Programmiergerät am Start hast, kannnst
du dem das sicher auch noch beibringen.
Hallo,
eine grundsätzliche Frage an S.L.
Funktioniert nur dieses Programm auf deinem AVRxEA nicht oder kannst du
flashen was du willst und es funktioniert überhaupt nichts? Weil das
klingt fast danach. Schon einmal Python sprich pymcuprog probiert?
Ich kann bis jetzt flashen mit Atmel ICE und ich kann flashen mit
pymcuprog & USB-Serial Wandler. Egal ob Kommandozeile oder aus Microchip
Studio heraus.
Einen Eigenbau Programmer ala jtag2updi hatte ich mir auch mittels
ATmega328PB gebaut. Klingt fast so als wenn du das mit AVRxDA gebaut
hast. Bekomme ich aber mit avrdude zusammen mit dem AVR64EA32 noch nicht
zum laufen. Connect mit ID auslesen funktioniert. Mehr auch nicht. Er
schreibt das Programm und meckert dann wegen fehlender Target Power was
es nicht prüfen kann. Der jtag2updi Programmer hat keinen VTG Pin wie
ein Atmel ICE.
Nach dem Versuch muss alles Stromlos gemacht werden, weil sonst der
Fehler mit falschen MCU Status erscheint. Mit Option -B 500 klappt es
auch nicht.
nochmal an Gerhard Hauptmann:
"Und fragen Sie 'Ich bitte', warum ich das denn tu - 's ist mal bei mir
so Sitte ..."
Nachdem ich recht schnell meine STK200-Phase hinter mir gelassen
hatte, programmierte ich die AVR8 mit einem Selbstbau-8085-System,
danach folgte ein Programmiergerät mit einem ATmega644 bzw. ATmega1284P.
Das heutige erlaubt mir gleichzeitigen Zugriff auf 3 zu
programmierende Controller (von unterschiedlichem Typ), ermöglicht
(rudimentäres) Debugging, stellt ein in weitem Bereich wählbares
Rechtecksignal zur Verfügung sowie ein im Bereich etwas eingeschränktes
Sinussignal, und misst Frequenzen und Perioden. Vier Spannungen und vier
Strombegrenzungswerte. Anschluss über RS232 oder USB. Auf einem
Lochrasterplatinchen 105*105, seit Mai 2020, genau vier Jahre.
an Veit Devil:
Die wenigen Dinge, die ich bislang auf dem AVR64EA28 probierte,
funktionierten, solange sie eben keinen Interrupt beinhalten.
Hallo,
Danke, bin zwar der Meinung die aktuelle Version verwendet zu haben,
kann es aber wiederholen und notfalls mit den Optionen spielt. Stimmt
mich jedenfalls positiv. Danke nochmal.
@ S.L.
Okay verstehe. sei() haste ja nicht wie ich vergessen. ;-)
Wirklich seltsames Problem mit deinem Controller.
S. L. schrieb:> programmierte ich die AVR8 mit einem Selbstbau-8085-System, danach> folgte ein Programmiergerät mit einem ATmega644 bzw. ATmega1284P.> Das heutige erlaubt mir gleichzeitigen Zugriff auf 3 zu programmierende> Controller
Danke S.L. das klingt ja alles sehr ambitioniert, gemessen an meinem
bescheidenen, fast nur offiziellen Atmel/Microchip- Toolset unter
Windows. Welche Implikationen Ihr Equipment für diesen Fall hier haben
könnte vermag ich nicht draus abzuleiten. Mein Interesse galt immer nur
eigenen Projekten, nie dem Werkzeug zum Programmieren und Debuggen
derselben. Damit bin ich allerdings stets hervorragend gefahren. Außer
der Unbenutzbarkeit von ein paar China JTAG-USB Adaptern unter Studio7,
welche mich in Einzelfällen noch zur Studio 4.19 Benutzung zwingen, gabs
da nie Probleme.
Es sollte jedenfalls niemandem in den Sinn kommen, daß Sie Ihren EA-Test
nicht mit der nötigen Fachkenntnis in Angriff genommen haben.
Würden Sie bitte vielleicht nun noch ein Foto Ihres widerspenstigen
Kandidaten zum Vergleich für die Allgemeinheit zur Verfügung stellen?
Daß es sich um eine Fälschung handelt dürfte ja weiter im (immer
kleineren) Kreis der Möglichkeiten anzusiedeln sein...
> Foto
Und auch hier muss ich Sie enttäuschen: ich gehöre zu den letzten
Mohikanern, die ohne SmartPhone existieren (können).
(und bin derzeit dabei, die beiden meterhohen Diakastensäulen zu
sichten & zu entsorgen)
Aber ich kann bei meinem Controller keinen Unterschied zu dem Ihrigen
erkennen, lediglich ist bei mir (auf der Unterseite) das Herstellerland
in Großbuchstaben geschrieben, im Gegensatz zu Ihrer Angabe.
PS:
Und um der nächsten Frage gleich zuvorzukommen: ich werde ganz sicher
nicht irgendjemanden bitten, mir sein SmartPhone zu leihen.
S. L. schrieb:> Okay, sieht bei mir genauso aus, auch die Orientierung der Schrift, nur> ist unten eben 'P5' (statt des 'O5') eingeprägt.
Alles keine äußeren Indizien für dunkle Machenschaften.
Es bleibt spannend. Wenn Ihr Ergebnis hier niemand reproduzieren kann
umso mehr.
Bei der nächsten Bestellung (was aber noch länger dauern wird) werde ich
die 2.77 für einen zweiten investieren, und auch gleich noch 2.55 für
einen AVR32EA28 - wenn diese dann bei mir auch keinen Interrupt
auslösen, liegt das Problem beim alten Landolt, dann können Sie alle
drei haben, kostenlos.
S. L. schrieb:> Bei der nächsten Bestellung (was aber noch länger dauern wird) werde ich> die 2.77 für einen zweiten investieren, und auch gleich noch 2.55 für> einen AVR32EA28 - wenn diese dann bei mir auch keinen Interrupt> auslösen, liegt das Problem beim alten Landolt, dann können Sie alle> drei haben, kostenlos.
Ein schönes Angebot, welches ich aber sehr gerne an Bedürftigere als
mich weiter gäbe. Ich hoffe viel eher Sie sind so ehrlich, das
Bekanntwerden der Ursache und selbige hier auf den Tisch des Hauses zu
packen :)
Mein AVR64EA28 lag heute mit im Paket. Hab es gerade probiert. Die
Variante von hier:
S. L. schrieb:> Okay, nächster Versuch
funktioniert bei mir auch. Ich habe dann noch etwas rumgespielt, ich
habe nichts entdeckt, was nicht meinen Erwartungen entspricht.
Auch mit sleep in der main läuft es wenn man den sleep nach Reset
enabled. Er schläft auch, ich habe in der main an einem 2. Pin
gewackelt. Die Periode ändert sich mit sleep dann so wie auch der
IRQ-Pin wackelt.
Alles hübsch. Na ja, war schon zu erwarten.
So jetzt hab ich ein weiteres Mitglied in der AVR-Kiste. Mal sehen, wann
ich den irgendwo hilfreich einsetzen kann :)
Nachtrag: Da ich Linux nutze: Ich habe AVRASM2 unter Wine genutzt zum
übersetzen und AVRDUDE zum flashen per ATMEL-ICE.
900ss schrieb:> Auch mit sleep in der main läuft es wenn man den sleep nach Reset> enabled.
Das werde ich in meinem Projekt gleich noch nachholen: Wenigstens ein
produktives Ergebnis dieses Threads. Ich dachte immer mit der
Sleep-Anweisung wäre es getan, nur der Sleep-Typ wäre ggf. noch zu
konfigurieren. Warum es aber extra einzuschalten ist?
900ss schrieb:> Gerhard H. schrieb:>> nur der Sleep-Typ wäre ggf. noch zu konfigurieren>> Das meinte ich mit "einschalten".> Also quasi das hier:>> ldi tmp0,0b00000_01_1 ; standby, enable>> sts SLPCTRL_CTRLA,tmp0
Dabei wird nur die Assembler-Anweisung Sleep explizit aktiviert (Bit0)
und konfiguriert (Bit1/2). Vorher ist sie wirkungslos. Dein Code allein
schaltet noch keinen Schlafmodus ein.
an 900ss:
Auch wenn ich mittlerweile völlig überzeugt bin, dass es sich um ein
singuläres Problem handelt, und nur für's Protokoll: was steht auf der
Ober- und was auf der Unterseite Ihres AVR64EA28?
Und danke für die Mühe, die Sie sich bislang machten.
Gerhard H. schrieb:> Dein Code allein> schaltet noch keinen Schlafmodus ein.
Ok, für Sie nochmal ausführlicher:
Folgende beiden Zeilen enablen den Sleep-Controller für den
Standby-Sleep-Mode.
1
ldi tmp0,0b00000_01_1 ; standby, enable
2
sts SLPCTRL_CTRLA,tmp0
Ist das nicht auch "Einschalten" des Sleep-Controllers? Und darum ging
es mir weil Sie explizit fragten:
Gerhard H. schrieb:> Warum es aber extra einzuschalten ist?
Ich habe nirgends geschrieben, dass der Controller damit in den
Sleep-Mode wechselt. Ich schrieb sogar:
900ss schrieb:> Auch mit sleep in der main läuft es wenn man den sleep nach Reset> enabled.
Hier ist also explizit erwähnt, dass in der main-Loop ein sleep-Befehl
existiert.
Ich bin mir sicher, dass Ihnen das auch vorher glasklar war.
S. L. schrieb:> was steht auf der> Ober- und was auf der Unterseite Ihres AVR64EA28?
Hallo, habe jetzt zwei Fotos gemacht. Dann können Sie mit Ihrem
Controller vergleichen.
S. L. schrieb:> Und danke für die Mühe, die Sie sich bislang machten.
Gerne, hat mich halt auch gejuckt. :) Und ich konnte mich mal wieder
etwas mit AVR-Assembler beschäftigen und hab auch noch was gelernt ;)
900ss schrieb:> Ok, für Sie nochmal ausführlicher
Für Dich ganz knapp: Kein Grund zur Aufregung.
Hab die Sachlage nur auf den Punkt bringen wollen.
Wir können zum eigentlichen Phänomen zurückkehren:
900ss schrieb:> Hallo, habe jetzt zwei Fotos gemacht. Dann können Sie mit Ihrem> Controller vergleichen.
Derselbe Date-Code.
S. L. schrieb:> Date-Code des verwendeten AVR64EA28: 2326URR
900ss schrieb:> Wer's glaubt...
Glauben ist nicht Wissen :)
Aber zum Phänomen zurück:
Der Vergleich der Beschriftung und mutmaßlich des von S.L. bereits
beobachteten Aussehens spricht wohl gegen eine Fälschung- auch wenn just
das entscheidende Puzzle-Teil-Foto des fraglichen Controllers unmöglich
scheint.
Ob wir den Grund dieser Interrupt-Dysfunktionalität jemals erfahren?
Um die (mittlerweile ausufernde) Angelegenheit abzuschließen:
Ich danke für die Angebote, aber dieses Controllerexemplar gebe ich
vorläufig nicht aus der Hand. Wie bereits geschrieben, werde ich bei der
nächsten Gelegenheit zwei EA mitbestellen, danach hier Bericht
erstatten.
Dass Zweifel aufkommen an meiner ungewöhnlichen IDE, das kann ich
nachvollziehen, aber die Zweifler mögen mir bitte konkret sagen, was ich
noch unternehmen bzw. woran es liegen könnte.
Im Anhang befindet sich nochmals eine Testversion für dieses
Interrupt-Problem: eine LED an PA6 flimmert, gerade noch erkennbar, mit
25 Hz bei einem AVR16EB28 sowie mit 30 Hz bei einem AVR128DA28, beim
AVR64EA28 bleibt sie dunkel. Wenn ich mir die Programmspeicherabzüge
(flash-dumps) ansehe, so sind sie gleich, zwischen dem EB und dem EA
sogar identisch - ich kann das für den EA assemblierte Intel-Hex-File
auf den EB flashen, und das Programm läuft dort.
Ich danke allen, die hier ihre Zeit und Energie (und in einem Fall sogar
Geld) investiert haben, und wünsche ein schönes Wochenende.
S. L. schrieb:> konkret sagen, was ich> noch unternehmen bzw. woran es liegen könnte
Aus dem was Ihre veröffentlichte Diagnose hier an Luft übrig lässt
eigentlich nur: Aktuelle Software, aktuelle Hardware nehmen so wie
jeder, der hier zu einem anderen Ergebnis kommt. Jener wird Ihnen dann
leider gleichfalls kaum sagen können, was mit Ihrem (eigenen) Equipment
älteren Datums schief läuft.
Daß ein Chip den von Ihnen beschriebenen Schaden hat ist in zweierlei
Hinsicht unwahrscheinlich: Erstens traue ich Ihnen genügend Erfahrung zu
diesen sachgerecht behandelt zu haben. Zweitens wäre das Durchrutschen
eines solchen Fehlers bei der Microchip Endkontrolle ja äußerst
beunruhigend: Dann würde man nie genau wissen ob der Controller den man
da aus seriöser Quelle kauft vertrauenswürdig wäre. Ich glaube das deckt
sich mit keinerlei Erfahrung. Meiner jedenfalls nicht.
Nun bliebe leider nur noch (das würden Sie sicher empört zurückweisen
und ich hielte es bei Ihrem Engagement auch für absolut unglaubwürdig),
daß uns hier jemand an der Nase herumführt...
> Wie bereits geschrieben, werde ich bei der> nächsten Gelegenheit zwei EA mitbestellen, danach hier Bericht> erstatten.
In der Erwartung auf neue Erkenntnisse - schönes Wochenende auch Ihnen!
S. L. schrieb:> beim AVR64EA28 bleibt sie dunkel
Posten Sie doch bitte einmal den passenden Hexfile zu dem EA. Ich werde
den hier mal flashen. Mal schauen was passiert. Ich glaube nicht dass es
am Hexfile liegt, aber.....
Noch mehr der EA hier auf dem Tisch ;)
S. L. schrieb:> beim> AVR64EA28 bleibt sie dunkel
Ich habe den File geflasht und mit dem Oszilloskop gemessen an PA6. Ich
messe ein Rechtecksignal mit 40ms Periodendauer. Sind also ca. 25Hz ;)
S. L. schrieb:>> 25Hz>> Wie beim EB: 20 MHz /6 /65536 /2 = 25.43 Hz.
Mein HP Frequenzzähler sagt 25.33Hz. Mein EA läuft zu langsam ;)
Ja das ist alles merkwürdig.
Man muss alles in Frage stellen. Den EA natürlich, den Aufbau. Ist er
identisch mit den anderen Controllern? Gleiches Netzteil? Und natürlich
auch Ihren selbstgebauten Programmer. Auch wenn dieser bei den anderen
Controllern funktioniert.
Der Programmer scheint ok zu sein. Aber....
Wenn Sie aber eh neue EA-Controller kaufen, würde ich solange warten.
Das schließt diesen dann eben aus oder auch nicht.
> ... Aufbau. Ist er identisch ...
Ich stecke lediglich die Controller auf dem Steckbrett um.
PS:
an Gerhard H.:
> daß uns hier jemand an der Nase herumführt
Das meinen Sie jetzt nicht wirklich, oder? Glauben Sie im Ernst, ich
(oder irgendjemand) könnte tatsächlich über einen solchen Thread mit 150
Beiträgen etwas vorlügen, ohne sich irgendwo zu verraten?
S. L. schrieb:> Ich stecke lediglich die Controller auf dem Steckbrett um.
Das ist echt verhext. Ich hab das nicht geprüft, die sind also
Pin-kompatibel?
Und dann sei mir eine Anmerkung erlaubt: Sie haben beide VDD und
GND-Anschlüsse des Controllers angeschlossen und auch einen
Abblock-Kondensator angeschlossen?
Bitte nicht falsch verstehen. Es könnte sein dass einige Controller
toleranter reagieren auf solche "Fehlerchen". Der EA aber doch nicht
will. Ich glaub es auch nicht, aber....
Was man nicht geprüft hat, weiß man nicht. Das ist meine Erfahrung.
> ... Anschlüsse des Controllers ... angeschlossen
So ist es, incl. zweier 100 nF Kondensatoren.
> Ja sind zu 100% pinkompatibel.
Wie auch AVR128DA28, AVR128DB28, AVR32DD28; nur dass die beiden
letztgenannten statt PD0 VDDIO2 haben.
PS:
> Anschlüsse
Wäre auch ein seltsamer Fehler, denn der EA läuft ja im Prinzip, die LED
an A7 glimmt, mit ca. 550 kHz.
S. L. schrieb:> So ist es, incl. zweier 100 nF Kondensatoren.
Da war ich geiziger, hab nur einen ;) Habe aber eben gelesen, dass es
zwei sein sollen.
Das Steckbrett... ich baue da auch hin und wieder was mit. Aber wenn die
Schaltung nicht funktioniert, dann fliegt das als erstes in die Ecke und
ich baue es auf Lochraster. Habe ich hier für den EA jetzt auch gemacht.
Ein IC-Sockel, 1 Kondesnsator und eine Pfostenleiste und da alles
notwendige angeschlossen.
S. L. schrieb:> Wäre auch ein seltsamer Fehler
Das stimmt, aber das ganze Problem ist seltsam. Und ich persönlich fange
dann an, solche Sachen in Frage zu stellen.
> Steckbrett ... fliegt ... als erstes in die Ecke
Da sind die Erfahrungen offenbar unterschiedlich: C-hater verstieg sich
einmal sogar zu der Behauptung, er könne seine nur wenige Male benutzen,
'Einmal-Wegwerf-Steckbretter' sozusagen; ich hingegen hatte meine ersten
vom Recyclinghof, und die hielten sehr lange, bis irgendwann manche
Vielbeiner (Controller etc.) manchmal heraussprangen, dann kaufte ich
neue - aber Kontaktprobleme hatte ich nie.
S. L. schrieb:> Das meinen Sie jetzt nicht wirklich, oder?
Nein, das meine ich jetzt nicht wirklich. Genau wie ich geschrieben
habe.
> Ich stecke lediglich die Controller auf dem Steckbrett um.
Puh. Sowas hatte ich noch nie im Einsatz. Immer alles festverlötet.
Allenfalls mit Präzisions-IC Sockel.
Haben Sie sich da vielleicht mal ver-steckt?
> Haben Sie sich da vielleicht mal ver-steckt?Mal versteckt? Das könnte ja nur beim allerersten Programmierversuch
gewesen sein, damals noch beim PIT-Interrupt aus dem sleep heraus -
das schließe ich aus; außerdem steht die Strombegrenzung auf 22 mA.
> Puh. Sowas hatte ich noch nie im Einsatz. Immer alles festverlötet.
Puh! Entwicklung fest verlötet - da käme ich auf keinen grünen Zweig.
S. L. schrieb:> das schließe ich aus
Kann es sein daß Sie inzwischen alles ausgeschlossen haben, es aber
trotzdem nicht funktioniert?
Nun ich vermute ein wenig enttäuscht, wir werden den Grund hier nicht
mehr erfahren - der irgendwo in einem äußerlich undurchsichtigen
Potpourri von veralteter IDE, eigenen Programmern und Steckbrettern vom
Recyclinghof verborgen sein muß.
Dabei hätten Effekte wie selektive Interrupt-Unfähigkeit das Zeug zu
ganz großen Erkenntnissen :)
Funktioniert bei einem Mikrocontroller der Interrupt nicht, so liegt ein
Sachmangel im Sinne von § 433 BGB vor.
In diesem Fall ist der Käufer berechtigt, einen Teil des Kaufpreises
zurückzuverlangen.
§ 434 BGB Sachmangel
§ 437 BGB Rechte des Käufers bei Mängeln
§ 441 BGB Minderung
Georg M. schrieb:> Funktioniert bei einem Mikrocontroller der Interrupt nicht, so liegt ein> Sachmangel im Sinne von § 433 BGB vor
Deine Rechts-Belehrung, die unmöglich auf einen in (unsachgemäßem)
Gebrauch befindlichen Mikrocontroller anwendbar ist rundet diesen
abstrusen Fall gekonnt ab. Dazu müsstest Du doch einen Serien-Fehler
nachweisen können- genau danach schaut es nur leider nicht aus.
S. L. schrieb:> Zwar kein Speicherabzug, aber die Intel-Hex-Datei ist genausogut: wenn> ich Ihr EATEST.hex in den AVR16EB28 flashe, blinkt die LED, bei meinem> AVR64EA28 blinkt sie nicht.
Ich bin etwas erstaunt. Lt. Datenblatt sind die IRQ-Vector Adressen für
RTC_PIT der beiden MCUs unterschiedlich:
AVR64EA28/32/48: Vector #5, Addr.: 0x0A
AVR16EB14/20/28/32: Vector #4, Addr.: 0x08
Was für mich bedeutet, dass der identische Binärcode für den
RTC-PIT-Interrupt nicht auf beiden MCUs lauffähig sein kann!
EATEST.lss:
1
.org RTC_PIT_vect
2
00000a ef0f ldi tmp0,$FF
3
00000b 9300 0153 sts RTC_PITINTFLAGS,tmp0
4
00000d 9a17 sbi IN_LED,LED
5
00000e 9518 reti
Bist Du Dir sicher, dass Deine IDE den RTC_PIT-Interrupt auf den
korrekten Vector mappt?
Grüßle,
Volker
> Bist Du Dir sicher, dass Deine IDE den RTC_PIT-Interrupt> auf den korrekten Vector mappt?
Ja; wie aus den flash-dumps, die in einigen der Programme unten
angehängt sind, zu ersehen ist.
Zu dem merkwürdigen Verhalten bei 'EATEST.hex -> AVR16EB28': warum die
LED trotzdem auf dem EB einwandfrei blinkt - gute Frage, der EB springt
ja mitten in den Befehl 'sts RTC_PITINTFLAGS,tmp0' hinein.
Beim zuletzt untersuchten TCB0 und seinem Interruptvektor sind die
Adressen übrigens gleich: 0x001A, sowohl bei EA als auch bei EB.
PS:
> Bist Du Dir sicher ...
Das hat ja erstmal nichts mit meiner IDE zu tun: das EATEST.hex von
Gerhard H. lässt auf einem EB die LED an PA7 blinken (warum auch immer).
Volker B. schrieb:> Was für mich bedeutet, dass der identische Binärcode für den> RTC-PIT-Interrupt nicht auf beiden MCUs lauffähig sein kann!S. L. schrieb:> lässt auf einem EB die LED an PA7 blinken
Das hab ich selber flugs mal überprüft.
Die PA7-LED blinkt mit selbigem EA Code auch auf dem EB.
Trotz verschiedenem PIT-Vektor.
S. L. schrieb:> der EB springt> ja mitten in den Befehl 'sts RTC_PITINTFLAGS,tmp0' hinein
Nein da täuscht Du Dich.
Der Einsprung-Vektor wird hier ja nicht durch Software sondern durch die
Hardware bestimmt: Der EB-PIT Einsprung erfolgt 1 Vektor-Position vor
der EA-PIT Position und gelangt so dennoch an den vollständigen
ISR-Code. Insofern ist alles OK mit der Lauffähigkeit auf beiden
Controllern.
Korrekt.
Der EB springt auf 0x0008 und führt dort, vor der eigentlichen ISR,
zweimal den Befehl FFFF aus, der erfahrungsgemäß wie ein nop (0000)
arbeitet.
Knut B. schrieb:> Deswegen arbeite ich mit für jeden Controller spezifischer und> kompletter Vektor-Tabelle. Immer.
Meine Rede.
Gerhard H. schrieb:> Eine komplette Interruptvektortabelle dient Ordnung, Übersicht,> Codewiederverwendbarkeit und Sicherheit: Irrtümlich aktivierte> Interrupts werden nämlich sicher abgefangen.
Insbesondere verhält sich Interrupt-Code dann controller-eindeutig. Die
LED wäre auf dem "falschen" Controller schlicht stumm geblieben. Für den
Platz den man damit zu verschenken glaubt spare ich mir lieber den Text
bemühten Vereinfachens über die ganze Umdefiniererei von Registern.
Warum ein tmp0 erfinden wenn man gleich direkt das Register, z B. r16
hinschreiben und daraus sofort ersehen kann was damit geht? Warum ein
IN_LED kreieren wenn mit VPORTA_IN,x im Code viel klarer ist wo jetzt
genau die Musik spielt? Naja, jeder wie er mag.
Hallo,
@ Knut
Warum extra Tabelle schreiben? Steht alles im Headerfile drin.
@ Gerhard H.
IN_LED vs. VPORTA_IN
Das macht schon Sinn. Muss man den Pin ändern, ändert man das Programm
nur an einer Stelle und muss nicht das gesamte Programm ändern. Es wird
überall das gleiche Register verwendet. Mal abgesehen von "Rename"
Möglichkeiten der IDE. Hat man irgendwo einen Tippfehler hilft auch
keine Rename Möglichkeit. Da wäre man wieder beim Vorteil von "IN_LED"
und klare sprechende Namen.
Veit D. schrieb:> Steht alles im Headerfile drin.
Das kann man sich für solche Zwecke natürlich einrichten und
inkludieren. Ggf. mitsamt diverser Initialisierungen.
Stichwort Code-Wiederverwendbarkeit.
> Muss man den Pin ändern, ändert man das Programm nur an einer Stelle und> muss nicht das gesamte Programm ändern.
Zu ändern ist doch höchst selten was wenn die Hardware (normalerweise)
vorab fertig ist.
> Hat man irgendwo einen Tippfehler
Mit Ruhe und Bedacht vom Kleinen zum Großen entwickelnd und dabei stets
neu assemblierend sind Tippfehler schnell aufgedeckt und beseitigt.
> klare sprechende Namen
Ich lasse lieber einen kurzen Kommentar daneben sprechen.
OK- die sprachlichen Möglichkeiten sind vielfältig- von bedingter
Assemblierung, sprechenden Namen bis extensivem Makro- Einsatz. Ich
bevorzuge eher minimalste, direkte, unverdeckte, nicht weiter
erklärungsbedürftige Ausdrucksformen. Wer sich bei Asm dagegen mit
möglichst viel "Komfort" einer Hochsprache annähern möchte sollte besser
gleich das Original wählen.
S. L. schrieb:> Das kann an den fehlenden zwischengeschobenen Status-Abfragen liegen,> siehe im Datenblatt '24.10 Synchronization': "it will take some RTC> and/or peripheral clock cycles before an updated register value is> available".
Das erinnert mich an den asynchronen Timer T1 des ATtiny861.
Sehr erstaunt war ich, daß nach Löschen des Interrupts und Freigabe
sofort der Interrupthandler angesprungen wurde. Ich mußte noch 2 NOPs
dazwischen einfügen, bis alle Bits aktualisiert waren. Grund sind die
Synchronisationsregister, da T1 auch mit der PLL 64MHz laufen kann
(siehe Bild). Diese Register sind auch dann wirksam, wenn T1 mit F_CPU
getaktet wird. Die PLL hatte ich ja nicht benutzt.
Bei den AVRs mit T2 als RTC gibt es ähnliche Effekte. Nur ist dann der
RTC-Takt wesentlich langsamer als der CPU-Takt.
Zwar habe ich Zweifel, dass sich noch jemand interessiert, zumal auch
der Hauptinteressent offenbar "über alle Berge" ist, aber ich hatte nun
mal versprochen, mich wieder zu melden, und Ordnung muss sein, also:
Ich habe nun einen weiteren AVR64EA28 sowie einen AVR32EA28 vorliegen,
und auch der zweite 64er funktioniert nicht, der 32er jedoch
einwandfrei. Da mir von anderer Seite versichert wurde, dass die 64er in
Ordnung sind, liegt es wohl an meiner ganz speziellen IDE (warum auch
immer), aber solange es keine Probleme mit den AVR32EA28 gibt, kann ich
damit leben.
S. L. schrieb:> liegt es wohl an meiner ganz speziellen IDE
Es gab doch weiter oben eine .hex-Datei, die laufen sollte und nichts
mit Deiner IDE zu tun hat. Läuft die auch nicht?
S. L. schrieb:> Zwar habe ich Zweifel, dass sich noch jemand interessiert
Es ist und bleibt interessant, wenn man diese µCs mal brauchen sollte.
Ich habe alles Mögliche versucht (ist ja auch über die 170 Beiträge
hinweg nachzulesen), .hex-Dateien hin&her geschoben zwischen AVR64EA28
und AVR32EA28 sowie auch AVR16EB28, habe Speicherabzüge verglichen und
was nicht alles, ohne einen Schritt weiterzukommen - "austherapiert",
würde ein Mediziner sagen.
Es muss wohl oder übel irgendwo bei mir liegen, aber ich komme nun mal
nicht dahinter, wo genau.
Mais oui, Veit Devil: ich habe die b-Version gewählt (aber auch nur
Ihnen zuliebe, mein Metier ist Assembler), und die blinkt auf meinem
32er, aber nicht auf dem 64er.
Aber lassen Sie uns nicht alles seit dem 02. Mai wiederholen - Sie
finden im Verlauf genügend andere und einfachere Beispiele. Ohne
wirklich neue Erkenntnisse ist für mich an dieser Stelle Schluss.
Hallo,
bei mir blinkt es auf einem AVR64EA32.
Bei dir auf einem AVR32EA28, aber nicht auf einem AVR64EA28.
Das mutet seltsam an. :-)
Deine Toolchain ist aber soweit okay?
Device Packs sind aktuell?
Um genau zu sein: blinkt auf meinem einzigen AVR32EA28, aber nicht auf
den beiden AVR64EA28.
Alles Weitere aber können Sie (viel) weiter oben nachlesen.