avr-attiny13 and avr-gcc, keine Reaktion

Am Sun, 11 Nov 2007 14:01:25 +0100 schrieb Oliver Joa:

Auf einem ATmega32 funktioniert das Programm. Bei 16 MHz Takt blinkt es mit "gefühlten" 3 Hz. Der ATtiny13 läuft per default mit 9,6 MHz, sollte da also etwas langsamer blinken.

Kannst Du nachmessen ob sich an den Pins (auch den anderen Pins) irgendwas tut? Ist die LED vielleicht verpolt eingebaut?

Kein Vorwiderstand??

an keinem Pin tut sich was. Die LED habe ich auch schon umgedreht.

doch. Multimeter zeigt auch nichts an. der Pin geht einfach nicht auf Low.

Olli

"Oliver Joa"

Bist du dir denn sicher, dass die While-schleife bei Null abbricht und nicht unterläuft?

Ansonsten: a) Wie ist die Diode anbeschlossen? b) Ist sie an oder aus? c) ist die Optimierung ausgeschaltet?

Ich habe auch schon folgendes probiert:

int main(void){ DDRB=0xFF; PORTB=0xFF; while (1) {;} ; }

als auch:

int main(void){ DDRB=0xFF; PORTB=0x00; while (1) {;} ; }

kein Unterschied! Der Pin (keiner) geht einfach nicht auf Low.

gegen +5V ueber einen 470 Ohm

Aus. Wenn ich am Pin messe, mess ich eine Spannung (etwas kleiner als Versorgungsspannung).

so kompiliere ich:

avr-gcc -g -mmcu=attiny13 -Wall -Wstrict-prototypes -mcall-prologues -c tsw.c avr-gcc -g -mmcu=attiny13 -Wall -Wstrict-prototypes -mcall-prologues -o tsw.out -Wl,-Map,tsw.map tsw.o avr-objcopy -R .eeprom -O ihex tsw.out tsw.hex

ich habe auch schon -Os probiert.

PB5 ist das Resetpin. Du löst einen Reset aus sobald du es auf 0 setzt.

Ich habe es auch schon so probiert:

DDRB|=1

der Vollstaendigkeit halber sieht die ganze Schaltung so aus:

und das Makefile:

MCU=attiny13 CC=avr-gcc OBJCOPY=avr-objcopy CFLAGS=-g -mmcu=$(MCU) -Wall -Wstrict-prototypes -Os -mcall-prologues all: tsw.hex tsw.hex : tsw.out $(OBJCOPY) -R .eeprom -O ihex tsw.out tsw.hex tsw.out : tsw.o $(CC) $(CFLAGS) -o tsw.out -Wl,-Map,tsw.map tsw.o tsw.o: tsw.c $(CC) $(CFLAGS) -Os -c tsw.c load: tsw.hex uisp -dlpt=0x378 --erase -dprog=dapa uisp -dlpt=0x378 --upload if=tsw.hex -dprog=dapa -v=3 --hash=32 clean: rm -f *.o *.map *.out *.hex

Ideen?

Danke

Olli

Oliver Joa schrieb:

Wirf ein Blick auf das Assembler-Listing. Da i und j nicht volatile sind, darf der Compiler deine komplette Delay-Schleife durch ein "ret" ersetzen - sie zeigt nämlich keine Nebeneffekte.

Benutze lieber die Delay-Kommandos aus der Bibliothek (IIRC util/delay.h)

Gruß, Johannes

Markus Gronotte schrieb:

Was soll denn das bitte sein? Unterlaufen als Gegenteil zum Überlaufen? Wie soll das gehen, bei einer vorzeichenbehafteten Variablen?

Gruß, Johannes

ein simples Einschalten der LED funktioniert schon nicht, also liegt es nicht an der while. Den Code habe ich von jemandem kopiert um zu pruefen dass es nicht an meinem eigenen liegt. Bei meinem eigenen habe ich sehr wohl volatile gesetzt.

Danke aber fuer den Hinweis auf die delay.h, kannte ich noch nicht.

Olli

Probier mal als Resetschaltung

VCC |

Und möglichst nah am Tiny 100 nF von VCC nach GND.

Hat schon so manchen Dreckeffekt beseitigt.

Gruß, Felix

Die Dinger heißen Zener-Dioden, das hat mit dem Herrn Zener zu tun, nicht mit der Zahl Zehn.

Sind die 100 nF wirklich ganz, ganz nah am Tiny? Wo kommen die 5 Volt her, sind die "gut"?

Schaltung mal vom Programmer abgetrennt, geht immer noch nicht?

Ansonsten würde ich mir trotzdem nochmal die Fuses anschauen, auch wenn Du meinst nichts dran geändert zu haben. Die können einem den ganzen Tag versauen ;-)

Gruß, Felix

Ja ok :-)

Ohne Programmer gehts auch nicht.

uisp -dlpt=0x378 -dprog=dapa --rd_fuses Atmel AVR similar to the AT90S1200 is found.

Fuse Low Byte = 0xff Fuse High Byte = 0xff Fuse Extended Byte = 0xff Calibration Byte = 0xff -- Read Only ReadLockBits failed: are you sure this device has lock bits?

Das Fuses-Zeugs check ich eh nicht so richtig. Jedenfalls habe ich mal am Atmega8 die Frequenz geaendert, laut einer Doku aus dem Internet. Das ging ganz gut, aber hier wuesste ich nicht wie ich es umstellen soll/kann oder was momentan eingestellt ist. Habe mich halt darauf verlassen dass im Default-Lieferzustand der interne Oszillator eingeschaltet ist. Ohne diesen duerfte eine Programmierung ja auch nicht gehen. Denke ich jetzt mal so :-)

Bin ja kein Elektronik-Profi...

Olli

Mit diesen Fuses ist der ATTiny13 nicht programmierbar. Da dürfte ein Problem mit dem Programmer vorliegen - es wird überhaupt nicht programmiert. Wenn die Fuses wirklich so wären würde der interne RC-Oszillator mit 128kHz schwingen und der ATTiny wäre nicht über SPI programmierbar. Datenblatt Seite 104. Ich würde erst einmal den Programmer und die Leitungen prüfen...

MfG Olaf

Wenn ich einen Attiny12 einsetze kommen sinnvollere Werte:

Atmel AVR ATtiny12 is found.

Fuse Low Byte = 0x52 Fuse High Byte = 0xff Fuse Extended Byte = 0xff Calibration Byte = 0x1e -- Read Only Lock Bits = 0xff BLB12 -> 1 BLB11 -> 1 BLB02 -> 1 BLB01 -> 1 LB2 -> 1 LB1 -> 1

Kann dann trotdem noch was an den Leitungen oder am Programmer nicht stimmen?

Olli

Wird währen des Programmierens RESET auf 0 gesetzt? Ich denke der ATTiny13 müßte erst einmal wie der ATTiny12 richtig erkannt werden damit es weiter geht. Olaf

Nachtrag: Wird der ATTiny13 überhaupt von uisp unterstützt?

These are the part names that UISP recognizes, using the -dpart parameter: AT90S1200, ATtiny12, ATtiny15, AT90S2313, AT90S2343, AT90S2323, AT90S2333, ATtiny22, ATtiny26, ATtiny2313, AT90S4433, AT90S4414, AT90S4434, AT90S8515, AT90S8535, ATmega8515, ATmega8, ATmega8535, ATmega161, ATmega163, ATmega16, ATmega162, ATmega169, ATmega323, ATmega32, ATmega64, ATmega103, ATmega128, ATmega103-old, AT89S51, AT89S52

Das wäre dann ein ernstes Problem...

MfG Olaf

Oliver Joa schrieb:

Das sieht ganz klar danach aus, als hätte dein Programmer Probleme, mit dem Attiny zu kommunizieren.

Ich kenne Deinen Programmer nicht, deshalb 2 Anmerkungen:

a) Dein 10-poliger ISP-Connector ist nicht so beschaltet wie die 10-polige STK-500-Programmierbuchse. Das kann jedoch OK sein, wenn auch Dein Programmer eine andere Belegung erfordert.

b) SCK wird über die LED im Optokoppler einigermassen niederohmig auf +5 V gezogen. Wenn der Ausgangstreiber deines Programmers etwas schwachbrüstig ist, kann das der Grund fürs Nichtfunktionieren sein. Löte mal R2 raus und probier's dann nochmal. Solange der Programmer den Chip nicht richtig erkennt (z.B. beim Auslesen der Fuses), brauchst erst gar nicht weitermachen.

c) Ansonsten bleiben noch die üblichen Verdächtigen: Lötbrücken, kalte Lötstellen, falsche Bauteilwerte, falschrum eingelötete Elemente...

Viel Erfolg, Jürgen