Attiny44A ; PDIP vs SMD - Übertragung schlägt fehl

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Aufgrund technischer Veränderungen ist der Mailverkehr innerhalb des Forums (Private Nachrichten) nur noch eingeschränkt möglich. Die Einschränkung ist notwendig, um zusätzliche Betriebskosten für das Forum zu vermeiden. Näheres zu den Hintergründen im Thread "Aktuelles zum Forum".Wir bitten um Verständnis.

    Hinweis kann nach Kenntnisnahme deaktiviert werden!

    • Hm, kann sein. Ich hätte gedacht, gleiche Bezeichnung - gleicher chip, nur halt in einem anderen Gehäuse eingeschmolzen. Ein 'A'-Typ unterscheidet sich natürlich vom 'nicht A'-Typ, klar.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Der Unterschied ist nur gering Miachaels Erklärung scheint schlüssig. In einem Fall mußte ich das LCD abklemmen damit der Brenner nicht "humpelt" während es beim Dip Typ so ging.
      Nun braucht der A-Typ etwas weniger Strom was darauf schließen lässt das er noch ein wenig weniger "kawum" hat und somit die untere Schmerzgrenze unterschritten ist. Ein bischen geht er ja noch sonst würde er gar nicht erkannt. Wie viele Fehler entstehen beim Schreiben? Einzelne Bytes oder alles FF? Ein Ozilloskop Verfügbar? Der Spannungsverlauf an Miso/Mosi könnte Aufschluß geben. Obwohl langsamer Clock meißt stabiliesierend wirkt wäre ein Versuch mit Vollgas (250kHz) vielleicht erfolgreicher.
    • Pluto25 schrieb:

      In einem Fall mußte ich das LCD abklemmen damit der Brenner nicht "humpelt" während es beim Dip Typ so ging.
      Oft wird vergessen, dass im Falle des Programmierens die Pins des AVRs auf Tristate liegen. Angeschlossene Geräte haben Enable oder Chip-Select Eingänge, die in dem Fall einem echten Pullup/Pulldown brauchen, damit es keine Probleme gibt.

      Pluto25 schrieb:

      Nun braucht der A-Typ etwas weniger Strom was darauf schließen lässt das er noch ein wenig weniger "kawum" hat und somit die untere Schmerzgrenze unterschritten ist. Ein bischen geht er ja noch sonst würde er gar nicht erkannt.
      Nein, das ist kreativ, aber das ist der falsche Schluss. Der A-Typ hat genausoviel Bumms wie der alte, tendenziell wird das sogar besser mit jeder Chipgeneration.
      Die Probleme entstehen beim Layout, fehlende Abblock-Kondensatoren oder auch schlechte Verbindungen im Steckbrett oder bei den (unsichtbar, weil unter Schrumpfschlauch) Verbindungskabel-Enden.
      Hier liegt auch nach meiner Vermutung das Problem, wenn ich mir Beitrag #10 anschaue.
    • daja schrieb:

      Schon mal mal hier gelesen ?

      mikrocontroller.net/topic/86305
      Ich denk' hier im link geht es darum, dass das stk500 board keine Fassung dafür anbietet. Im thread hier werden die chips auf ein breadboard gesteckt und mit Drähten an den Programmer angeschlossen.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Wenn ich nichts übersehen hab steht noch die Antwort aus welcher Programmer benutzt wird. Ich hab mit attiny84 egal in welchen revisionen und ob smd oder dil nie probleme gehabt. Testaufbau in dil aufm Steckbrett, dann in smd mit angelöteten ISP Leitungen. Der 44er ist ja an sich nix anderes als ein 84er
      Ich benutz den 20 eur Diamex Programmer in neuer und alter revision.
      Die Probleme klingen für mich nach Spannungsschwankungen und eher noch zu hoch eingestellter clock.
    • Hallo! Entschuldigung für die verspätete Antwort meinerseits.

      Programmer ist einer auf STK500 Basis anscheinend. Einen Namen hat das Kind nicht.

      Beim letzten Versuch habe ich den Controller direkt angelötet und auch ohne Verbraucher versucht zu flashen. (Kein Erfolg)
      Nachdem ich dann nun attiny44 (ohne A) genommen habe, sah es in mehreren Versuchen so aus als würde er das Programm übertragen (Fenster hat sich auch geschlossen ohne Fehlermeldung), doch dann lief das Programm auch nicht auf dem Controller. (Kein LED blinken)

      Was ich eventuell nochmal probiere:
      - schnelleren clock (kleinster Wert bisher)
      - Attiny84 (oder -24)
      - externe Spannungsquelle. (bisher 5V vom USB-Port)

      So die Lasten hab ich an den Ausgängen nicht. Es ist jeweils nur eine LED+Widerstand.
      Mittlerweile habe ich zwei Attiny85 benutzt, was wieder einwandfrei funktioniert hat.
    • Wenn du Interesse daran hast, dass es mal ein anderer mit seiner Ausrüstung probiert, dann sag Bescheid. Ich würde es mal mit meinem AVRISPMK2-programmer versuchen, wenn du mir einen tiny per Brief schickst. Fax ist schlecht, der wird mir in's Gerät fallen, zum Aufschrauben hab' ich jetzt keine Lust. Also, wenn du Interesse hast, melde dich und du bekommst du meine Adresse per PN.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Zwischen 24,44 und 84 hatte ich nie einen Unterschied festgestellt. Ein Programmer-programm das das Fenster schließt? Keine Erfolgsmeldung kein Verifizieren? Versuch mal den Bascom integrierten. Er ist recht mitteilsam. Dort muß der Chip vor dem Schreiben gelöscht werden und später per Befehl verifiziert (falls gewünscht).
      @tschoeatsch ich habe hier auch einen. Gibt es die Möglichkeit seinen Clock auf unter 4khz zu bringen?
    • @Pluto25 keine Ahnung. Vielleicht mit dem studio? Seit ich meinen Avrispmk2 habe, hab' ich den immer mit bascom betrieben und auch noch kein firmwareupdate gemacht. Er hat immer funktioniert.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Ich benutze den Bascom-integrierten.
      "Atmel STK500 protocol compatible Programmer" steht drüber und bei der Schaltfläche "Erase and programm chip" schließt sich bei mir nach (normalerweisem) erfolgreichem flashen das Fenster.

      Bisher hatte ich auch nie Probleme, und auch sonst mit anderen Attinys gibt es kein Problem.
    • @tschoeatsch Dann vergiß bitte nicht das div8 bit zu löschen bevor Du einen Chip mit 128 kHz betreiben willst, sonst läuft er auf 16 kHz und wird unidentified.
      @Flimmy in der Tat. Die habe ich total übersehen. Bisher habe ich immer "zu Fuß" -Erase -Brennen und wenn der Chip nicht richtig tickte oder woanders hin gebracht werden mußte -Verify.
      Schließt sich das Fenster auch wenn was nicht stimmt? Führt er ein Verify aus? Aber selbst wenn würde mir die beruhigende "Alles Gut" Meldung fehlen.
    • @Pluto25 deine Empfehlung verstehe ich jetzt nicht. Nach meiner Kenntnis gibt es intern der RC mit 8MHz und das fusebit div8. Div8 ist im Auslieferungszustand gesetz, sowie intern RC, der Takt beträgt also 1MHz. Das ist doch problemlos zu handeln. Über einen Registereintrag kann man den Systemtakt tiefer setzen, so verstehe ich das Datenblatt, aber das wäre doch nicht von Dauer. Hab' ich da jetzt was falsch verstanden?
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Der Systemtakt läßt sich auf 128kHz fusen. Was dann 16kHz werden wenn das Div8 nicht abgeschaltet wird.
      Das Feintunig mit dem Register habe ich noch nicht probiert da der Clock im Gegensatz zur Vref recht gut hinkommt . Die Abweichung summiert sich nur auf ein paar Minuten am Tag.
      Erinnere ich mich da falsch ? Hoher Bereich von 50-200% ? Zu viel Korrektur durchs Register macht ihn instabiel?
      Das Calibation-Byte wird nach Reset wieder ins OSCAL geschrieben womit Du Deine Korrektur beibehalten könntest.
    • Ich hab' die Kontroller von @Flimmy bekommen und hab' als erstes mal den attiny44 verkabelt
      attiny44.jpg
      und die fuses gelesen
      attiny44-fuses.PNG
      und dann dieses Testprogramm geflasht

      BASCOM-Quellcode

      1. $regfile = "attiny44.dat"
      2. $crystal = 1000000
      3. $hwstack = 32
      4. $swstack = 16
      5. $framesize = 48
      6. Config Porta = Output
      7. '$sim
      8. Porta.4 = 1
      9. Porta.5 = 0
      10. Do
      11. Wait 1
      12. Toggle Porta
      13. Loop
      14. End
      Alles anzeigen
      alles ohne Probleme und die Led an einem pin von porta blinkt.
      Ich verwende den AVRISPMK2.
      Ich werd' noch gelegentlich den attiny44A verkabeln und testen.
      @Flimmy, schick mir doch mal deine Datei, die du drauf haben möchtest, dann brenn ich den tiny gleich.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------