Meine Attinys lassen mich im moment im Stich, ich habe eine Schaltung gelötet ein NPN Transistor mit Vorwiderstand an die Ausgänge meines Attiny2313. Nach dem Programmieren was erfolgreich funktionierte, keine Funktion. Mit dem Multimeter nachgemessen stellte ich keine Ausgangsspannung fest. Ungläubig baute ich eine Schaltung auf ein Steckbrett nur aus dem Chip und dem 6 poligen Programmiersockel für mein AVR MKII. Ein simples Ausgabeprogramm geschrieben wieder keine Spannung an keinem Pin gemessen, weder PIN <-> GND oder VCC <-> PIN. Egal welchen PIN oder PORT ich nahm und egal ob dieser als ausgang mit einer 1 oder 0 beschalten wurde. Habe auch mal einen Pulldown eingebaut jedoch immer noch keine Spannung messbar. Hier mein Programm: .include "tn2313def.inc" ldi r16,0xff out DDRB,r16 ldi r16,0xff out PORTB,r16 ende: rjmp ende Die Eingangsspannung gemessen am Attiny beträgt genau 5.0V aus Batterien und in der aufgebauten Schaltung ist noch kein Verbraucher nur der Chip im Leerlauf. Seriennummer ist auslesbar Chip ist Programmierbar. Nun dachte ich, da wird der Chip kaputt sein aber nein, das hier ist schon der 3. der nicht möchte. Das ich so versagen kann?
Auf welchem Pegel befindet sich der Reset-Pin bei deinen Tests? Vielleicht befindet sich der Controller dauerhaft im Reset, sodass er garnichts ausgeben kann?
Brutzel schrieb: > Nach dem Programmieren was erfolgreich funktionierte, Schreibe mal im Detail, wie du dabei vorgehst.
wenn die Versorgungsspannung nicht optimal ist, schlägt vielleicht die Brown out Erkennung an und hält den µC im Reset. Entweder die Brown out Schwelle per Fuses verringern, deaktivieren oder für eine gute Spannungsversorgung sorgen inkl. der Kerkos zw. (A)VCC/GND. Ein kleiner Elko paar µF vor die Kerkos schadet auch nicht. Resetbeschaltung 10 kOhm Pullup und noch nen kleinen Kerko ich verwende auch hier immer 100nF in manchen Empfehlungen sind aber auch kleinere Werte vertreten.
Beim Programmieren gehe ich wie folgt vor: -Device Programming -Chip eingeben -Targetvoltage 5.0V -Device Signature eine HEX Dezimalzahl nicht rot umrandet Nachdem alles eingestellt ist, einfach das Programm auf den Chip schreiben: Done building project "ATTiny2313.asmproj". Build succeeded. ========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ========== scheint funktioniert zu haben. Nun habe ich mit meinem Multimeter gemessen ein x beliebiger Pin der nach dem Programm auf HIGH sein muss (Habe wie erwähnt sämtliche Ports und pins versucht) im Moment messe ich an allen Pins 0.25V vereinzelt hatte ich auch mal 1.8 oder 3V wie erwähnt jeder Ausgang ist mit 5k Ohm an GND geschalten. Zwischen RESET und GND habe ich 5V mit 10,2k Ohm gegen VCC Die 5V Spannung kommen aus 6 Batterien um genau zu sein Mignon Größe AA, es sind alte NiCd Akkus mit 800mAh die Zellspannung der 4 Akkus wird insgesamt um 1 V gefallen sein was ja nur Positiv sein kann da 5V Optimal sein müssten.
Brutzel schrieb: > Die 5V Spannung kommen aus 6 Batterien (...) > NiCd Akkus mit 800mAh die Zellspannung der 4 Akkus Was denn jetzt? - 6 Batterien? - 4 Akkus? - 4 Batterien? - 6 Akkus? Du machst deinem "Namen" alle Ehre!
ohje, entschuldigung. 4 NiCd Akkus in Reihe geschaltet. Es sind Akkus der Größe AA mit diesen 4 in Reihe geschalteten Akkus komme ich auf eine Spannung von exakt 5V das ist meine Spannungsquelle. Selbes Ergebnis habe ich jedoch auch, wenn ich als Spannungsquelle ein Computernetzteil verwende welches ebenfalls 5V (5.1V) liefert
Brutzel schrieb: > Selbes Ergebnis habe ich jedoch auch, wenn ich als Spannungsquelle ein > Computernetzteil verwende welches ebenfalls 5V (5.1V) liefert Autsch, sicher, dass das stabil ist? Gewöhnlich brauchen die Dinger eine Grundlast um sauber anzulaufen. Wie siehts denn mit dem Takt aus? Intern oder extern mit Quarz? Brutzel schrieb: > vereinzelt hatte ich auch mal > 1.8 oder 3V wie erwähnt jeder Ausgang ist mit 5k Ohm an GND geschalten. Vielleicht ist deine Messerei Murks? Wer zu viel misst, misst Mist. Einen Ausgangswiderstand brauchts da gewöhnlich nicht. 5k belastet so einen Port aber auch nicht, sofern es wirklich 5k sind. Lass Widerstände mal weg und mess dann. Außer die Idee nach dem Upload noch einen Reset auszulösen und dann zu messen fällt mir langsam auch nichts mehr ein.
Bist du auch wirklich sicher, dass der Tiny programmiert wird? Oben schreibt du was von build succeeded, aber build ≠ programming.
Ich bin mir ziemlich sicher, dass er programmiert wurde es steht ja Build 1 Succied Die Widerstände um die Ports zu belasten habe ich wahlweise hinzugefügt und weggelassen mit den gleichen Ergebnissen. Grundlast hat mein Netzteil keins und meine Akkus erstrecht nicht. Im gegenteil ich hatte mit dem Netzteil nie Probleme auch nicht bei Akkubetrieb und mein atmega8515 funktioniert, sowie vorherige schaltungen mit dem attiny ich wüsst nun aber auch nicht was ich anderst mache als sonst. Am Takt habe ich nichts verändert sonst hätte ich es erwähnt, die chips laufen mit dem Internen Takt ich denk mal 1MHz
Leuchte schrieb: > Ich bin mir ziemlich sicher, dass er programmiert wurde es steht ja > Build 1 Succied Wir sind uns ziemlich sicher, das ein "Build" nur das Binary erstellt, es aber nicht in den AVR flasht. Das ist normalerweise ein extra Schritt.
>nur das Binary erstellt, es aber nicht in den AVR flasht. Das ist > >normalerweise ein extra Schritt. Dabei soll es auch schon mal vorgekommen sein das ein falsches Binary geflasht oder ein Binary das für einen anderen Controller übersetzt wurde;)
Du kannst ja mal im Atmel Studio direkt per device programming versuchen deinen Tiny zu programmieren. Dann kannst du dir wenigstens 100% sicher sein, dass die Programmierung erfolgreich war.
Ich habe nun mein Programm mit Device Programming in den Chip geschrieben: Programm: \Atmel Studio\6.1\ATTiny2313\ATTiny2313\Debug\ATTiny2313.hex Programming EEPROM...OK Verifying EEPROM...OK Muss noch Korrigieren der Chip läuft mit 8MHz Internem Takt mit 64ms anlaufzeit
Brutzel schrieb: > Programming EEPROM...OK > Verifying EEPROM...OK Hi, und geht jetzt? Wenn das alles an Meldung war dann eher nicht. Dein Progreamm steht jetzt wohl im Eeprom. Im Flash wäre es besser aufgehoben... Brutzel schrieb: > Muss noch Korrigieren der Chip läuft mit 8MHz Internem Takt mit 64ms > anlaufzeit ... und vermutlich dem Taktteiler 8, wenn Du nicht an den Fuses rumgefummelt hast, also mit 1MHz. Gruß, Norbert
Habe das Programm in den Flash geschrieben: Erasing device... OK Programming Flash...OK Verifying Flash...OK Die Messergebnisse ändern sich nun, wahlweise habe ich 5V oder 0V an einem gesamten Port, dies stimmt jedoch nicht immer mit dem Programmierten Überein An den Fuses fummel ich eigentlich nichts auser cksel und da steht immoment: INTRCOSC_8MHZ_14CK_64MS
Ich sehe gerade noch ein Fuse, CKDIV8 das ist vermutlich was du meinst, da ist ein harken hintendran.
Hi, mit der Software oben schaltest Du ja auch den ganzen PortB. Dafür reicht mein ASM so gerade ;-) Brutzel schrieb: > An den Fuses fummel ich eigentlich nichts auser cksel und da steht > immoment: > INTRCOSC_8MHZ_14CK_64MS Und Clockdiv_8 ist gesetzt, also läuft er mit 1MHz. Edit: Ahh, selber gemerkt. So kommen alle neueren AVR aus der Fabrik. Gruß, Norbert
:
Bearbeitet durch User
Ja aber was mir nun aufgefallen ist ein Beispiel: Ich schalte PORT A mit dem Wert 0xAA (10101010 binär) ich stelle fest es funktioniert es folgt ein weiterer Befehl mit PORT B ich setze ihn auf 0xff (11111111) es funktioniert, eine Neuerung ich schalte Port B auf 0xAA port A bleibt unverändert. Nun ist Port A was die Spannung an geht richtig jedoch an allen Pins von PORT B Plötzlich 0V Die PORTS schalten wie sie grade wollen plötzlich war PORT D auf 5V dieser wird im Programm garnicht erwähnt.
Brutzel schrieb: > Ich schalte PORT A mit dem Wert 0xAA (10101010 binär) ich stelle fest es > funktioniert es folgt ein weiterer Befehl mit PORT B ich setze ihn auf > 0xff (11111111) es funktioniert, eine Neuerung ich schalte Port B auf > 0xAA port A bleibt unverändert. Hi, lies nochmal was Du geschrieben hast. Passt doch. Was PortD anzeigt wenn da nichts gesetzt wird ist zufällig. Die Pins sind komplett offen. Wenn Du mal die Software jeweils posten würdest wenn etwas nicht so tut wie Du erwartest wäre das hilfreich. Gruß, Norbert
Gerne, im Moment habe ich diese Software im Flash: .include "tn2313def.inc" ldi r16,0xAA out DDRA,r16 ldi r16,0xAA out PORTA,r16 ldi r16,0xFF out DDRB,r16 ldi r16,0xFF out PORTB,r16 ende: rjmp ende Ergebnis: PA0 = 5V PA1 = 5V PA2 = 5V(RESET) PB0 - PB7 = 0V
Hi, hoppla, hab falsch gelesen. Poste bitte die Software und was sie jeweils macht. Bei dieser Prosa gibt es zuviele Missverständnisse. Gruß, Norbert
Software und Messergebnis in meinem vorherigem Beitrag, morgen bastel ich diese kleine Schaltung mal auf ein anderes Steckbrett und programmiere mim Laptop, manchmal muss man einfach die Umgebung verändern, ich arbeite so viel mit dem Attiny2313 und wenn von heut auf morgen 3 chips spinnen dann muss ich doch was falsch machen
Hi, ok, das sollte so nicht sein. Misst Du an den richtigen Pins? Richtige Software geflasht? Einem von beiden Fehlern gebe ich 80% als Ursache. Wenn das korrekt ist: Kerkos an Reset und Versorgung? Direkt am µC? Gruß, Norbert
Ein Abblockkondensator im Sockel eingebaut So oft wie ich nun schon gemessen habe und geprüft ja es sind die richtigen pins nach dieser Grafik http://hobby-electrons.sourceforge.net/components/ATtiny2313/ATtiny2313.png und hätte ich den chip falsch herum ginge er nun schon in Rauch auf :) Die Software ist auch korrekt Namenlich unverwechselbar. Ich danke dir für deine Hilfe Norbert und Prüfe morgen weiter.
Eingangspins haben in der Regel aktivierte Pullup Widerstände deswegen 5V. Entweder du schaltet diese ab oder setzt das PUD Bit.
Thomas O. schrieb: > Eingangspins haben in der Regel aktivierte Pullup Widerstände deswegen > 5V. Entweder du schaltet diese ab oder setzt das PUD Bit. Das ist ein Gerücht, daß ich von dir zum erstenmal gehört habe. Belege dafür?
Schau ins Datenblatt dort findet man die Infos, wozu sollte es sonst das PUD(Pullup disable) Bit geben?
> Das ist ein Gerücht So ist es. > Eingangspins haben in der Regel aktivierte Pullup Widerstände deswegen > 5V. Entweder du schaltet diese ab... Wie sollte dieses Abschalten aussehen? Datenblatt: § I/O-Ports, Switching Between Input and Output When switching between tri-state ({DDxn, PORTxn} = 0b00) and output high ({DDxn, PORTxn} = 0b11), an intermediate state with either pull-up enabled {DDxn, PORTxn} = 0b01) or output low ({DDxn, PORTxn} = 0b10) must occur. Normally, the pull-up enabled state is fully acceptable, as a high-impedant environment will not notice the difference between a strong high driver and a pull-up. If this is not the case, the PUD bit in the MCUCR Register can be set to disable all pull-ups in all ports.
Hi, naja, das PUD gibt es aber das hat eben einen anderen Zweck. Wenn man den Port nicht angefasst hat sind aber DDRXn und PORTXn 0 und somit die Pullups aus. Von daher ist Thomas O. schrieb: > Eingangspins haben in der Regel aktivierte Pullup Widerstände Unsinn. Gruß, Norbert
Tritt das Problem eigentlich bei verschiedenen Controllern auf? Wenn ja, üperprüfe folgende Dinge (und zwar sorgfältig und nicht nach dem Motto: das müsste schon passen): - Verkabelung (mit Ohmmeter alle Leitungen von Anfang bis Ende) - Versorgungsspannung (alle Massen verbunden etc.) - Taktversorgung - Und bitte nochmal ganz genau und auch mit verschiedenen Programmen (Atmel Studio, avrdude): Programmierung der Controller Wenn das Problem jedoch nur an einem Controller auftritt, dann an anderen überprüfen. Eventuell ist der Controller einfach hinüber Freundlichen Gruß von jemandem, der selbst gerne die einfachsten Fehler übersieht (z.B. AVR zu schwach ins Steckbrett gesteckt ...)
NSA schrieb: > (z.B. AVR zu schwach ins Steckbrett gesteckt ...) Ja, da hilft die stumpfe Seite eines Beils und bei den kleineren AVR ein Durchschlag.
Also wenn man nur Basten will, dann ist das hier diskutierte alles ok und man sollte nach diesem Satz nicht weiterlesen. Wenn man ernsthaft Software und/oder Hardware entwickeln möchte, dann nutzt man eine stabile Entwicklungsumgebung wie z.B. ein SDK500 oder SDK600 um so die hier ellenlang diskutierten (HW) Fehlerquellen auszuschließen. Nimmt eine vernünftige IDE wo man nicht mit Makefiles oder anderen glyphisch zu bedienenden Tools herumflashen muss. Dann evaluiert man die SF auf dem SDK, gegebenenfalls im debuggmodus. Externe HW und nur die kommt aufs Breadboard. Laufen die einzelnen Parts fehlerfrei kann man anfangen irgendetwas zu löten. Warum das Ganze? Weil es einem am Ende hilft die Fehlerquelle zu identifizieren. Klar kostet alles etwas. Aber man spart eine Menge Zeit. Mit der gesparten Zeit kann man sich dann einen Ferienjob suchen und das ganze finanzieren ;-)
Ich bin jetzt nicht so der Knüller was ASM angeht aber sind das nicht unterschiedliche Befehle für PORTX.Y = 1 und PORTX.Y = 0?
Ihr habt recht, die Pullups werden nur aktiviert wenn man bei einen Eingangspin eine 1 ausgibt ( ins PortX Register) Es gibt hier aber eine Menge Beiträge "wieso der Analogwandler immer 1023 bzw. 255 ausgibt" oder "wieso 5V am Eingangspin anliegen" und das liegt dann an aktivierten Pullups.
Also nachdem ich die Schaltung neu aufbaute , funktioniert alles wenn ich den Chip mit Device Programming programmiere :) Nun noch eine Frage wenn ich den Programmpfad meines zu programmierenden Programmes wähle und es auf den Chip schreib ist alles in Ordnung. Sobald ich das Fenster schließe, dass Programm änder und Device Programming wieder öffne, ändert sich die Dateiendung im Pfadfeld von .hex zu .elf weswegen er das Programm bei einem Klick auf "Program" nicht sofort findsen kann. Ich muss dann erst wieder den Pfad und das Programm auswählen, ist natürlich extrem zeitraubend, wieso ändert er die Dateiendung in seinem Eingabefeld beim schließen des Fensters. Und wo wir bei Zeit sind, bisher habe ich meine Chips mit einem Tastendruck auf F5 Programmieren können, ist zwar nach der Beschreibung "continue" nicht der richtige Weg doch es funktionierte einmal und immer wieder und ich war es von anderen IDE´s gewohnt mit F5 zu programmieren. Da dies nun anscheinend von einer Sekunde auf die Andere nicht mehr funktioniert frage ich, was ist die schnellste Methode eine kurze Änderung auf den Chip zu bringen.
Hi, ich arbeite mit AVRdude und mache mir dafür eine Batch. Statt Filename einfach "%1" (ohne "") und in den selben Ordner packen wo das Kompilat landet. Dann zieht man das Kompilat einfach auf die Batch und los gehts. Vorteil ist auch, daß man irgendwann alle Batchvarianten hat, also Mega88, intern 8MHz, 3V. Diese Eckdaten kommen in den Namen der Batch. Gruß, Norbert
Normalerweise kannst du im Atmel Studio auch direkt mit dem Build programmieren und musst gar nicht den Umweg über das Device programming gehen.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.