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.
Es kann ja nicht allzu schwer sein das Datenblatt zu lesen. Oder soll eine alte Library zum Einsatz kommen ? Wild heruntergeladener Code ?
:
Bearbeitet durch User
Kein Problem. Schau mal in den Code meines Projekts Beitrag "Li-Akku Reihenschaltung einzeln nacheinander laden (Switch-Control) Asm@AVR64EA28" Allerdings Asm.
Prima, verbindlichen Dank! Im Laufe des Nachmittags schaue ich es mir an.
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.
:
Bearbeitet durch User
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.
Nochmal etwas reduziert, ganz ohne sleep. (wobei Letzteres ursprünglich für mich der Ausgangspunkt war, ich sollte unter 1 uA (bei 3.0 V) kommen)
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.
:
Bearbeitet durch User
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. ;)
:
Bearbeitet durch User
an 900ss: Oh, Sie können sicher aufzeigen, was an der Version von 17:47 falsch ist - helfen Sie mir.
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üft Ob 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.
:
Bearbeitet durch User
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 ;)
:
Bearbeitet durch User
Sehen Sie, da haben Sie heute noch etwas gelernt; auch wenn es in Ihren Augen Unfug ist. Ich armer Tor hingegen bin so klug als wie zuvor.
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
S. L. schrieb: > notfalls bleibt mir ja noch immer der Umstieg auf den AVR16EB28 - der > läuft bei mir. Bemerkenswert. Leider nur mit 1/4 Flash :)
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'.
Beitrag #7658046 wurde vom Autor gelöscht.
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.
:
Bearbeitet durch User
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.
Johann L. schrieb: > Geheimnis: Das geht auch mit SBI. ;) Das wird jetzt offtopic, ich will das hier nicht ausweiten. Bin auf die Lösung gespannt :)
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.
Angehängte Dateien:
-
AVR_RTC_PIT.png
40 KB
Funktioniert wenigstens der RTC? Der PIT ist nämlich nicht so unverzichtbar wie der RTC. Der PIT ist eigentlich nur ein Appendix am RTC.
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.
Angehängte Dateien:
-
DB_Vergleich.png
220 KB
Dann laden Sie mal das aktuelle herunter: '© 2021 Microchip Technology Inc. Complete Datasheet DS40002183C-page 1 and its subsidiaries'
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.
Übrigens, der PIT funktioniert auch ohne Interrupt. (Ob das jemand gebrauchen kann...) Aber die LED blinkt:
1 | #include <avr/io.h> |
2 | |
3 | int main(void) |
4 | {
|
5 | PORTA.DIRSET = PIN3_bm; |
6 | |
7 | RTC.CLKSEL = RTC_CLKSEL_INT1K_gc; |
8 | while(RTC.PITSTATUS > 0) {} |
9 | RTC.PITCTRLA = RTC_PERIOD_CYC1024_gc | RTC_PITEN_bm; |
10 | |
11 | while(1) |
12 | {
|
13 | if(RTC.PITINTFLAGS) |
14 | {
|
15 | RTC.PITINTFLAGS = RTC_PI_bm; |
16 | PORTA.OUTTGL = PIN3_bm; |
17 | }
|
18 | }
|
19 | }
|
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.
Im "Silicon Errata" wird auch SLPCTRL.CTRLA erwähnt, k.A. ob es relevant sein könnte.
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.
Irgendwie seltsam. Aber das Leben geht weiter. Und wenn der RTC nicht für höhere Ziele geplant ist, dann kann man auf den PIT einfach verzichten.
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
Beitrag #7660897 wurde vom Autor gelöscht.
Angehängte Dateien:
-
avr64ea28.jpg
59 KB
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?
:
Bearbeitet durch User
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'
:
Bearbeitet durch User
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 :)
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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...
:
Bearbeitet durch User
> 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 :)
:
Bearbeitet durch User
> 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'?
S. L. schrieb: > Wohnen Sie in Radel-Distanz von Freiburg i.Brsg.? Leider nein, war aber gerade näher dran (Tübingen) als jetzt zuhause ...
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..
:
Bearbeitet durch User
Also wenn es der SIB ist:
1 | AVR64EA28: |
2 | 41 56 52 20 20 20 20 20 50 3A 33 44 3A 31 2D 33 |
3 | ein alter AVR128DA28: |
4 | 20 20 20 20 41 56 52 20 50 3A 32 44 3A 31 2D 33 |
:
Bearbeitet durch User
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.
C-hater, könnten wir bitte zum eigentlichen Problem zurückkehren? Nochmal: fragten Sie nach dem 'System Information Block'?
1 | AVR64EA28: |
2 | 41 56 52 20 20 20 20 20 50 3A 33 44 3A 31 2D 33 |
3 | A V R P : 3 D : 1 - 3 |
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.
Beitrag #7661008 wurde vom Autor gelöscht.
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?
:
Bearbeitet durch User
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. :-)
:
Bearbeitet durch User
Angehängte Dateien:
-
20240507_103430.jpg
270 KB
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).
:
Bearbeitet durch User
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 :)
:
Bearbeitet durch User
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...
:
Bearbeitet durch User
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. :(
Angehängte Dateien:
-
DeviceInfo.png
25 KB
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.
Georg M. schrieb: > Veit D. schrieb: >> Weder der RTC- noch der PIT ISR Interrupt funktionieren. > >
1 | > sei(); |
2 | >
|
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 :)
:
Bearbeitet durch User
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
1 | rtcstatus |
2 | ldi tmp0,0b0_1101_00_1 ; /16384 + enable |
3 | sts RTC_PITCTRLA,tmp0 |
zusammen zuweisen.
Veit D. schrieb: > zusammen zuweisen Na das tut er doch. Siehe sein Code. RTC_PITINTCTRL und RTC_PITCTRLA sind verschiedene Register...
:
Bearbeitet durch User
Hallo, hattest du meine Dateien gelesen? Dieses verodern funktioniert, am Ende eine Registerzuweisung der "Summe".
1 | uint8_t temp = 0; |
2 | temp |= RTC_PRESCALER_DIV1024_gc; // Prescaler 1024 |
3 | temp |= RTC_RUNSTDBY_bm; |
4 | temp |= RTC_RTCEN_bm; // enabled |
5 | RTC.CTRLA = temp; // set Config |
Das hier funktioniert nicht - bei diesem Controller !
1 | RTC.CTRLA |= RTC_PRESCALER_DIV1024_gc; // Prescaler 1024 |
2 | RTC.CTRLA |= RTC_RUNSTDBY_bm; |
3 | RTC.CTRLA |= RTC_RTCEN_bm; // enabled |
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.
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. :-)
:
Bearbeitet durch User
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 :)
:
Bearbeitet durch User
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!
Angehängte Dateien:
-
Synchronisation.jpg
110 KB
> 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.
:
Bearbeitet durch User
Veit D. schrieb: > Dieses verodern funktioniert, am Ende eine Registerzuweisung der > "Summe". >
1 | > uint8_t temp = 0; |
2 | > temp |= RTC_PRESCALER_DIV1024_gc; // Prescaler 1024 |
3 | > temp |= RTC_RUNSTDBY_bm; |
4 | > temp |= RTC_RTCEN_bm; // enabled |
5 | > RTC.CTRLA = temp; // set Config |
6 | >
|
>
Das ist nichts anderes als1 | RTC.CTRLA = RTC_RUNSTDBY_bm | RTC_PRESCALER_DIV1024_gc | RTC_RTCEN_bm; |
oder kurz gesagt
1 | RTC.CTRLA = 0xD1; |
Hallo, natürlich ist das nichts anderes. Das soll es ja auch bezwecken.
S. L. schrieb: > PPS: > Und weil heute Feiertag ist, noch ein nettes Cartoon dazu. Der ist ziemlich gut :-)) Wünsche einen schönen Feiertag.
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.
1 | RTC.CTRLA |= RTC_PRESCALER_DIV1024_gc; |
2 | while (RTC.STATUS > 0) { ; } |
3 | RTC.CTRLA |= RTC_RUNSTDBY_bm; |
4 | while (RTC.STATUS > 0) { ; } |
5 | RTC.CTRLA |= RTC_RTCEN_bm; |
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
1 | avrdude -c jtag2updi -P com5 -p avr64ea32 -v -U flash:w:avr64ea32rtc.hex:i |
Fehler
1 | avrdude: Version 7.3 |
2 | Copyright the AVRDUDE authors; |
3 | see https://github.com/avrdudes/avrdude/blob/main/AUTHORS |
4 | |
5 | System wide configuration file is C:\avrToolchain\avrdude\avrdude.conf |
6 | |
7 | Using port : com5 |
8 | Using programmer : jtag2updi |
9 | Programmer baud rate : 115200 |
10 | Setting bit clk period: 500.0 us |
11 | AVR Part : AVR64EA32 |
12 | Programming modes : UPDI, SPM |
13 | Programmer Type : JTAGMKII_UPDI |
14 | Description : JTAGv2 to UPDI bridge |
15 | Main MCU HW version : 1 |
16 | Main MCU FW version : 6.00 |
17 | Sec. MCU HW version : 1 |
18 | Sec. MCU FW version : 6.00 |
19 | Serial number : 00:00:00:00:00:00 |
20 | avrdude: silicon revision: 2.1 |
21 | avrdude: AVR device initialized and ready to accept instructions |
22 | avrdude: device signature = 0x1e961f (probably avr64ea32) |
23 | avrdude: Note: flash memory has been specified, an erase cycle will be performed. |
24 | To disable this feature, specify the -D option. |
25 | avrdude: erasing chip |
26 | |
27 | avrdude: processing -U flash:w:avr64ea32rtc.hex:i |
28 | avrdude: reading input file avr64ea32rtc.hex for flash |
29 | with 294 bytes in 1 section within [0, 0x125] |
30 | using 3 pages and 90 pad bytes |
31 | avrdude: writing 294 bytes flash ... |
32 | Writing | #################################----------------- | 66% 0.23 s |
33 | avrdude jtagmkII_paged_write() error: bad response to write memory command: RSP_NO_TARGET_POWER |
34 | avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER |
35 | ***failed; |
Kann jemand dazu vielleicht Hinweise geben was falsch läuft?
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.
Veit D. schrieb: > Kann jemand dazu vielleicht Hinweise geben was falsch läuft? Gibt ein Kapitel dazu in der jtag2upfi Beschreibung: https://github.com/ElTangas/jtag2updi?tab=readme-ov-file#timeouts
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.
> sei() haste ja nicht ... vergessen.
Sonst wäre ja auch das (identische) Programm nicht auf den anderen
Controller-Typen gelaufen.
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...
:
Bearbeitet durch User
> 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.
:
Bearbeitet durch User
Angehängte Dateien:
-
20240509_202017.jpg
180 KB
S. L. schrieb: > Herstellerland in Großbuchstaben geschrieben Darauf hatte ich gar nicht geachtet, ja es sind Großbuchstaben.
Okay, sieht bei mir genauso aus, auch die Orientierung der Schrift, nur ist unten eben 'P5' (statt des 'O5') eingeprägt.
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.
:
Bearbeitet durch User
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 :)
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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?
:
Bearbeitet durch User
Gerhard H. schrieb: > nur der Sleep-Typ wäre ggf. noch zu konfigurieren Das meinte ich mit "einschalten". Also quasi das hier:
1 | ldi tmp0,0b00000_01_1 ; standby, enable |
2 | sts SLPCTRL_CTRLA,tmp0 |
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
Angehängte Dateien:
-
Draufsicht.jpg
420 KB -
VonUnten.jpg
500 KB
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
:
Bearbeitet durch User
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?
:
Bearbeitet durch User
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 ;)
:
Bearbeitet durch User
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?
:
Bearbeitet durch User
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.
900ss schrieb: > die sind also Pin-kompatibel? Gerade selber mal für den AVR16EA28 geprüft. Ja sind zu 100% pinkompatibel.
> ... 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.
:
Bearbeitet durch User
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?
:
Bearbeitet durch User
> 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
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
> 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).
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Beitrag #7663917 wurde vom Autor gelöscht.
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.
Deswegen arbeite ich mit für jeden Controller spezifischer und kompletter Vektor-Tabelle. Immer.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Angehängte Dateien:
-
Async_T1.png
52 KB
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.