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?
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.
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
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
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
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.
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?
> 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 ...)
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
;-)
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
