Hallo,
ich wende mich nun in völliger Ratlosigkeit an euch.
Momentan Programmiere ich auf einem Atmega8515, dort klappt auch
alles ohne Probleme, nur da ich für mein Programm nun auch einen ADC
brauche, binn ich auf einen ATtiny85 umgestiegen. Nun aber folgendes
Problem:
Ich kann ohne Probleme den Mircokontroller Programmieren oder die
Fusebits ändern. Nur arbeitet der Tiny nicht.
Habe zuerst an mein Programm gedacht das ich dort fehler drin habe,
nur als ich dann das banale einschalten eines Pins versuchte, klappte
nicht einmal das.
Alle Verbindungen sind mehrfach kontrolliert und funktionsfähig.
Der Tiny läuft mit den Internen 8 MHz, Prescaler deaktiviert.
Watchdog timer ist nicht aktiviert.
Reset Spannung stimmt, Spannung ist mit entsprechenden abblock
Kondensatoren versehrt.
2 Tinys wurden durch Probiert um einen defekt auszuschließen.
Programmiert wird es über einen ISP MKII Programmer von Atmel.
Die Portspannung an allen I/O Pins bleibt bei 0V.
Der simple C-Code:
1
#include<avr/io.h>
2
3
intmain(void)
4
{
5
DDRB=0xff;
6
PORTB=0xff;
7
8
while(1)
9
{
10
PORTB=0xff;
11
}
12
}
Nun meine Frage, woran könnte es liegen das der Tiny nicht arbeitet?
Ist zu dem Zeitpunkt der ISP-Connector auch abgezogen?
Es sieht nämlich so aus, würde die CPU per RESET festgehalten.
Ausserdem würde ich mal nur einen PIN von PORTB wackeln lassen, damit
man mit dem Ozi etwas messen/sehen kann. Oder mach mal eine LED mit
Vorwiderstand an bspw. PB0.
Der 85er hat nur PORTB! das sind ALLE Pins.
der alte Hanns schrieb:> Dumme Frage eines Assembler-Programmierers: Das gezeigte Programm kann> doch nicht alles sein, wo steht, dass es sich um einen ATtiny85 handelt?
Das wird durch die Makros der IDE festgelegt. Diese steuern welche
Makros dann tatsächlich in der io.h eingebunden werden.
In C muss man nicht alles umständlich auf Händen und Füssen machen, da
kann man schon mal einfach losrennen ;-)
Ich hatte genau das gleiche Problem mit einer ganzen Latte von AVRs, die
ich mit Atmel Studio programmieren wollte. Probier doch mal Folgendes:
Lösche manuell (unter Device Programming) den Speicher des Chips
(Memories) und programmiere ihn dann noch mal. Erst das hat meine
vermeintlich kaputten Chips zum Laufen gebracht, trotz angeblich
fehlerfreien Programmiervorgangs.
cyblord ---- schrieb:> Das wird durch die Makros der IDE festgelegt. Diese steuern welche> Makros dann tatsächlich in der io.h eingebunden werden.
Danke für die Nachhilfe. Das heißt, dieser MKII Programmer liest die
Chipkennung und teilt sie der IDE mit, und die IDE bindet die korrekte
.inc-Datei ein?
@ LP
was erhoffst du dir von dem Schaltplan?
hättest du nach dem Board gefragt oder wie ich es aufgebaut habe ok,
aber bei dem simpeln Tiny einen Schaltpan?
Das sind 3 Kondensatoren, ein 6pin anschluss, der Tiny und ein
Wiederstand.
@bastler
Nope mein Oszi zeigt weiterhin durchgehend 0Volt
@Rush
Der SPI MKII Programmer zieht nur beim Programmieren die Spannung auf 0V
Das Toggeln eines Pins habe ich auch probiert und dies funktioniert auhc
nicht.
@der alte Hannes
Dies wird mit den I/O include im avr sudio6 geregelt.
@Phillip K.
Ja habe ich gerade probiert und leider klappt dies auch nicht.
@Alter Hannes
Ja der MKII ließt die Chip ID aus, und gleicht damit die ausgewählte
I/O mit der ID ab, wenn dies passt kann der chip Programmiert werden.
>Ja der MKII ließt die Chip ID aus, und gleicht damit die ausgewählte>I/O mit der ID ab,
Nö. Das musst du schon selber tun.
Ich tippe darauf das die HEX Datei für die falsche
CPU übersetzt wurde.
L. P. schrieb:> Schaltplan bitte.
Bin zwar nicht L. P., aber ich meine ein Schaltplan hilft:
1. dass du dir nochmals bewusst wirst, was du wirklich verdrahtet hast.
2. dass wir unserer Glaskugel nicht bemühen müssen.
und
3. dass du dein Problem gelöst kriegst.
der alte Hanns schrieb:> cyblord ---- schrieb:>> Das wird durch die Makros der IDE festgelegt. Diese steuern welche>> Makros dann tatsächlich in der io.h eingebunden werden.>> Danke für die Nachhilfe. Das heißt, dieser MKII Programmer liest die> Chipkennung und teilt sie der IDE mit, und die IDE bindet die korrekte> .inc-Datei ein?
Nein. Das ist C, da gibts keine .inc Dateien.
In der IDE wird der Controller ja eingestellt. Die IDE ruft den
Präprozessor so auf, dass gewisse Makros gesetzt sind. Über
Präprozessor-Anweisungen wird dann bestimmter Quellcode eingebunden oder
auch nicht. Das sind dann die #if/#endif Statements. So werden in der
io.h dann nur die Dateien eingebunden welche für den ensprechenden
Controller die korrekten Makros definieren.
Macro-Magic ist wichtig in C.
gruß cyblord
holger schrieb:> Nö. Das musst du schon selber tun.> Ich tippe darauf das die HEX Datei für die falsche> CPU übersetzt wurde.
In dem Fall wären wir genau da, wo ich auch hinwollte.
der alte Hanns schrieb:> holger schrieb:>>> Nö. Das musst du schon selber tun.>> Ich tippe darauf das die HEX Datei für die falsche>> CPU übersetzt wurde.>> In dem Fall wären wir genau da, wo ich auch hinwollte.
Nope denn dann gibt AVR Studio eine Fehlermeldung aus weil dann
die ausgelesene chip ID nicht mehr mit der, der ausgewählen
Optionen übereinstimmt. Glaubt mir den fehler hatte ich schon mal
in meiner anfangszeit gehabt.
und im anhang mal der Schaltplan
>>> Ich tippe darauf das die HEX Datei für die falsche>>> CPU übersetzt wurde.>>>> In dem Fall wären wir genau da, wo ich auch hinwollte.>>Nope denn dann gibt AVR Studio eine Fehlermeldung aus weil dann>die ausgelesene chip ID nicht mehr mit der, der ausgewählen>Optionen übereinstimmt. Glaubt mir den fehler hatte ich schon mal>in meiner anfangszeit gehabt.
In meinem AVR Studio 4.18 kann man die CPU in den
Projekt Properties einstellen und im Programmierdialog.
Wenn ich die CPU im Programmierdialog ändere, ändert sich
die CPU in den Projekt Properties nicht.
Und Sie haben wirklich einen 85 drin, nicht den 13 wie im Schaltplan?
Ich will Ihnen nicht zu nahe treten, demont, aber vor kurzem hatten wir
den Fall, dass jemand statt mit einem TDA2822 mit einem TBA820
'arbeitete', weil er versäumt hatte, die Lieferung zu kontrollieren.
holger schrieb:>>>> Ich tippe darauf das die HEX Datei für die falsche>>>> CPU übersetzt wurde.>>>>>> In dem Fall wären wir genau da, wo ich auch hinwollte.>>>>Nope denn dann gibt AVR Studio eine Fehlermeldung aus weil dann>>die ausgelesene chip ID nicht mehr mit der, der ausgewählen>>Optionen übereinstimmt. Glaubt mir den fehler hatte ich schon mal>>in meiner anfangszeit gehabt.>> In meinem AVR Studio 4.18 kann man die CPU in den> Projekt Properties einstellen und im Programmierdialog.> Wenn ich die CPU im Programmierdialog ändere, ändert sich> die CPU in den Projekt Properties nicht.
Wer hat hier etwas gesagt das sich hier etwas ändert???
Es wird lediglich eine Fehlermeldung ausgegeben und man kann den
MC dann nicht programmieren... btw, ich verwende AVR Studio!!!6!!!
der alte Hanns schrieb:> Und Sie haben wirklich einen 85 drin, nicht den 13 wie im> Schaltplan?> Ich will Ihnen nicht zu nahe treten, demont, aber vor kurzem hatten wir> den Fall, dass jemand statt mit einem TDA2822 mit einem TBA820> 'arbeitete', weil er versäumt hatte, die Lieferung zu kontrollieren.
ja ich hatte mir nicht die Mühe gemacht den 85 im eagle 6.2.0 anzulegen,
da ich gesehen habe das diese beiden das gleiche pinout haben.
Und Ja ich es ist ein Tiny85 20SU
Magnus M. schrieb:> C2 muss zwischen RESET und GND.
Das ist aber nicht die Ursache wieso der tiny nicht arbeitet.
Programmieren kann man ihn ja, genauso kann man ihn auslesen oder
die Fusebits ändern...
Dennoch habe ich es angepasst und es ändert nichts an der lage....
katastrophenheinz schrieb:> Nur um auszuschließen, das Code für den falschen AVR-Typ> compiliert> wird:> Mach mal diese Abfrage vor dein main():#if ! defined(_AVR_ATtiny48_)> #error "Wrong AVR Type!"> #endif
geht problemlos durch (mit 85)
Folgendes wäre vielleicht einen Versuch wert, um zu sehen, ob er
überhaupt losläuft:
fuse low byte bit no 6: CKOUT einschalten
und auf PB4 nachschauen, ob dort die 8 MHz erscheinen.
der alte Hanns schrieb:> Folgendes wäre vielleicht einen Versuch wert, um zu sehen, ob er> überhaupt losläuft:>> fuse low byte bit no 6: CKOUT einschalten>> und auf PB4 nachschauen, ob dort die 8 MHz erscheinen.
kommen 8.001.973 Hz raus :/
Dann kann es doch eigentlich nur noch am Programm selbst liegen.
Können Sie das Programm aus dem ATtiny85 wieder auslesen und als Hexdump
hier vorstellen?
Wie ist das Verhalten, wenn du vor der While-Schleife die beiden
Anweisungen vertauscht, also erst PullUps ein, dann Output ?
PORTB = 0x3f;
DDRB = 0x3f;
katastrophenheinz schrieb:> Wie ist das Verhalten, wenn du vor der While-Schleife die beiden> Anweisungen vertauscht, also erst PullUps ein, dann Output ?>> PORTB = 0x3f;> DDRB = 0x3f;
dein Ernst? :D
Pull ups werden gesetzt wenn vorher der Port als Eingang definiert
wurde.
Somit wird in meinem Fall direkt nach dem der Port als Ausgang definiert
wurde, der Komplette Port B auf 1 gesetzt, um sicher zu gehen das dies
auch
wirklich geschieht habe ich es nochmals im Hauptbrogramm gemacht in der
While schleife.
demont schrieb:> dein Ernst? :D
Ja, im AVR-Manual halten die sich beim Beispielcode an diese
Reihenfolge.Aber egal.
Guck mal, ob der µC überhaupt aus dem reset kommt.
Dazu main() soweit ausdünnen:
int main(void)
{
PORTB = 0x3f;
while(1);
}
Eigentlich müsste jetzt an den Eingängen durch die internen PullUps ein
High-Pegel messbar sein.
Wie sind R und C an der Reset-Leitung dimensioniert?
katastrophenheinz schrieb:> demont schrieb:>> dein Ernst? :D> Ja, im AVR-Manual halten die sich beim Beispielcode an diese> Reihenfolge.Aber egal.>> Guck mal, ob der µC überhaupt aus dem reset kommt.> Dazu main() soweit ausdünnen:> int main(void)> {> PORTB = 0x3f;>> while(1);> }> Eigentlich müsste jetzt an den Eingängen durch die internen PullUps ein> High-Pegel messbar sein.>> Wie sind R und C an der Reset-Leitung dimensioniert?
Leider auch da keine änderung am Port...
Wie ich schon sagte, der Tiny arbeitet nicht.
R = 4k7 c = 100n
spess53 schrieb:> Hi>> Ignorieren, wenn die Frage schon gestellt und beantwortet wurde:>> Wird uberhaupt das richtige HEX-File geflasht?>> MfG Spess
wird ignoriert
der alte Hanns schrieb:> Dann kann es doch eigentlich nur noch am Programm selbst liegen.
Das ist die logische Konsequenz.
> Können Sie das Programm aus dem ATtiny85 wieder auslesen und als Hexdump> hier vorstellen?
Genau das wäre die sinnvollste Eskalation des Debugging. Fakten und kein
blödes Geschwafel. Mit Hilfe des Dump ließen sich nämlich ein Großteil
aller möglichen Fehlursachen problemlos ausschließen.
...sehr merkwürdig, also nochmal alles zusammengefasst:
- der interne Oszillator rennt, sonst könntest du den µC nicht
programmieren, und PB4 zeigt den passenden Clock Output
- mit dem vorherigen Beispiel liegt immer noch ein low-pegel am Port (
an welchem hast du gemessen und wie hast du gemessen ? )
Sieht so aus, als ob der µC nicht den Reset-Zustand verlässt.
Vielleicht nochmal den C an der Reset-Leitung komplett raus und nur den
PullUp dranlassen, PullUp auf 10k erhöhen
Und poste bitte mal das .lss-file, das der Compiler auswirft.
So im Anhang die eeprom.hex und flash.hex
katastrophenheinz schrieb:> ...sehr merkwürdig, also nochmal alles zusammengefasst:> - der interne Oszillator rennt, sonst könntest du den µC nicht> programmieren, und PB4 zeigt den passenden Clock Output> - mit dem vorherigen Beispiel liegt immer noch ein low-pegel am Port (> an welchem hast du gemessen und wie hast du gemessen ? )> Sieht so aus, als ob der µC nicht den Reset-Zustand verlässt.>> Vielleicht nochmal den C an der Reset-Leitung komplett raus und nur den> PullUp dranlassen, PullUp auf 10k erhöhen>> Und poste bitte mal das .lss-file, das der Compiler auswirft.
Ja interner Oszi rennt. An PB4 kann ich mit meinem Oszi bei
entsprechender
fusesetzung den Takt sehen. Das Signal kontrolliere ich an Pin 2 und 3
mit einem Oszi.
... grad gemacht, keine Veränderung
.lss-file?
katastrophenheinz schrieb:> der alte Hanns schrieb:>> Stimmt es, dass auch im Reset-Zustand der Clock-Output zu sehen ist?>> ja, tiny85-manual "Alternate Functions of Port B"
Also ich habe es eben ausprobiert, sobald ich reset auf GND lege
verschwindet die Frequenz an PB4.
demont schrieb:> So im Anhang die eeprom.hex und flash.hex
Was ist das? So wie aus dem µC ausgelesen? Flash-File jedenfalls nicht
das, das der Compiler auswirft, denn es ist komplett "leer"
Generiertes Flashfile liegt irgendwo im/unter dem Quellcodeverzeichnis
und heißt <Projektname>.hex
der alte Hanns schrieb:> katastrophenheinz schrieb:>> der alte Hanns schrieb:>>> Stimmt es, dass auch im Reset-Zustand der Clock-Output zu sehen ist?>>>> ja, tiny85-manual "Alternate Functions of Port B">> Also ich habe es eben ausprobiert, sobald ich reset auf GND lege> verschwindet die Frequenz an PB4.
Gerade auch ausprobiert, wenn ich einen reset auf null lege,
liegt kein Taktsignal mehr auf PB4 an.
katastrophenheinz schrieb:> demont schrieb:>> So im Anhang die eeprom.hex und flash.hex>> Was ist das? So wie aus dem µC ausgelesen? Flash-File jedenfalls nicht> das, das der Compiler auswirft, denn es ist komplett "leer">> Generiertes Flashfile liegt irgendwo im/unter dem Quellcodeverzeichnis> und heißt <Projektname>.hex
so nun die korrekte im anhang
der alte Hanns schrieb:> Also ich habe es eben ausprobiert, sobald ich reset auf GND lege> verschwindet die Frequenz an PB4.
Dann spinnt das Manual:
CLKO: The devided system clock can be output on the pin PB4. The divided
system clock willbe output if the CKOUT Fuse is programmed, regardless
of the PORTB4 and DDB4 settings. It will also be output during reset.
katastrophenheinz schrieb:> Dann spinnt das Manual:>> CLKO: The devided system clock can be output on the pin PB4. The divided> system clock willbe output if the CKOUT Fuse is programmed, regardless> of the PORTB4 and DDB4 settings. It will also be output during reset.
Da mögen Sie Recht haben, etwas weiter oben steht:
The device can output the system clock on the CLKO pin (when not used as
XTAL2 pin). To
enable the output, the CKOUT Fuse has to be programmed. This mode is
suitable when the chip
clock is used to drive other circuits on the system. Note that the clock
will not be output during
reset and that the normal operation of the I/O pin will be overridden
when the fuse is programmed
spess53 schrieb:> Hi>>>so nun die korrekte im anhang>> Das hast du aber nicht aus dem Cobtroller ausgelesen. Das nämlich> interessiert.>> MfG Spess
oh ok dann hatte ich das falsch verstanden. Gut habe nun den kontroller
ausgelesen.
datei im Anhang
>Flash-File jedenfalls nicht>das, das der Compiler auswirft, denn es ist komplett "leer"
Passt aber zu seiner Beschreibung.
Der Controller macht nichts.
>Gut habe nun den kontroller>ausgelesen.>datei im Anhang
Da steht viel mehr drin als einmal DDR und PORT setzen.
Du hast die falsche Hex Datei geflasht.
Das was der Compiler auswirft, sieht ok und passend zum tiny85 aus (
.lss, .hex )
Das im ausgelesenen .hex passt aber nicht dazu.
Machst du nach dem Schreiben des Flash ein Verify?
>Da steht viel mehr drin als einmal DDR und PORT setzen.>Du hast die falsche Hex Datei geflasht.
Oder mal auf Chip Erase klicken bevor das nächste
Programm reingeflasht wird.
Vorschlag: mit dem ATmega8515 hat das ganze Verfahren ja funktioniert,
wenn es nicht zuviel Aufwand ist, es mit diesem nochmal versuchen.
Vielleicht ist dann zu erkennen, was bei dem tiny schief läuft.
holger schrieb:>>Gut habe nun den kontroller>>ausgelesen.>>datei im Anhang>> Da steht viel mehr drin als einmal DDR und PORT setzen.> Du hast die falsche Hex Datei geflasht.
ok dann hat leider es nicht so geklappt wie ich dachte.
Wie kann ich mit AVR S6 die hexfiles auslesen?
hatte das letzte gesendete hatte, versuchte ich mit Bascom raus zu
siehn...
der alte Hanns schrieb:> Vorschlag: mit dem ATmega8515 hat das ganze Verfahren ja> funktioniert,> wenn es nicht zuviel Aufwand ist, es mit diesem nochmal versuchen.> Vielleicht ist dann zu erkennen, was bei dem tiny schief läuft.
was versuchen?
der alte Hanns schrieb:> katastrophenheinz schrieb:>> Dann spinnt das Manual:>>>> CLKO: The devided system clock can be output on the pin PB4. The divided>> system clock willbe output if the CKOUT Fuse is programmed, regardless>> of the PORTB4 and DDB4 settings. It will also be output during reset.>> Da mögen Sie Recht haben, etwas weiter oben steht:>> The device can output the system clock on the CLKO pin (when not used as> XTAL2 pin). To enable the output, the CKOUT Fuse has to be programmed. This mode> is suitable when the chip clock is used to drive other circuits on the system.> Note that the clock will not be output during reset and that the normal> operation of the I/O pin will be overridden when the fuse is programmed
:-o Dieser Absatz sagt genau das Gegenteil hinsichtlich Clock Output bei
Reset. Und Ihre Untersuchung bestätigt das.
der alte Hanns schrieb:> Dasselbe wie beim tiny, eben einen Ausgang auf high setzen.
hehe, sry aber ich kann dort mit knapp 800khz daten auf einen Pin
ausgeben... also ja das klappt wunderbar...
ich scheitere nur bei dem banalen versuch auf einen anderen Controller
um zu steigen... :/
Hi
>Wie kann ich mit AVR S6 die hexfiles auslesen?
Im Programmierdialog gibt es einen Buttom 'Read'. Aber merk dir, wo du
das gespeichert hast.
MfG Spess
Nun, ich hatte gemeint, dass Sie jetzt dieses Miniprogramm in den
ATmega8515 bringen, laufen lassen, das pin-high verifizieren und dann
den hex-dump ziehen.
Nochmal ganz blöd gefragt:
Wie flasht du das (korrekt erzeugte) LED_tiny85.hex von oben auf den µC?
Und machst du ein Verify nach dem Schreiben?
Und hast du Holgers Voschlag "Chip Erase" mal verfolgt, um ggf LockBits
zurückzusetzen?
Erstelle erstmal ein neues Projekt mit dem Tiny85 als Ziel und einem
komplett neuen Verzeichnis.
Dann mittels Bitmanipulation einen Pin toggeln wie das in C geht steht
im Tutorial.
An den Pin dann eine LED anschließen oder mit Multimeter messen ob
zwischen GND und VCC umgeschaltet wird.
Nicht mit voller Frequenz toggeln, entweder delay_ms oder Timer nehmen
...
Wenn das dann auch nicht klappt ist entweder etwas im Studio total
verkonfiguriert oder Dein Tiny85 hat eine Macke ...
Da bekanntlich viele Köche den Brei verderben, verabschiede ich mich an
dieser Stelle.
Aber gestatten die Herren noch eine abschließende Bemerkung:
cyblord ---- schrieb:> In C muss man nicht alles umständlich auf Händen und Füssen machen, da> kann man schon mal einfach losrennen ;-)
Ursprünglich wollte ich dahingehend antworten, dass es in meinemAlter mit dem 'einfach losrennen' so eine Sache ist, jetzt sehe ich
aber, dass auch die Jüngeren damit ihre Probleme haben.
der alte Hanns schrieb:> Nun, ich hatte gemeint, dass Sie jetzt dieses Miniprogramm in den> ATmega8515 bringen, laufen lassen, das pin-high verifizieren und dann> den hex-dump ziehen.
Wenn ich nun wüsste wie ich diese hex-dump ziehen kann gerne,
aus dem vorherigem werde ich nicht schlau
katastrophenheinz schrieb:> Nochmal ganz blöd gefragt:> Wie flasht du das (korrekt erzeugte) LED_tiny85.hex von oben auf den µC?> Und machst du ein Verify nach dem Schreiben?> Und hast du Holgers Voschlag "Chip Erase" mal verfolgt, um ggf LockBits> zurückzusetzen?
Über das AVR Sudio 6
und ja und auch das hatte ich schon beantwortet mit ja
cppler schrieb:> Erstelle erstmal ein neues Projekt mit dem Tiny85 als Ziel und> einem> komplett neuen Verzeichnis.> Dann mittels Bitmanipulation einen Pin toggeln wie das in C geht steht> im Tutorial.> An den Pin dann eine LED anschließen oder mit Multimeter messen ob> zwischen GND und VCC umgeschaltet wird.> Nicht mit voller Frequenz toggeln, entweder delay_ms oder Timer nehmen> ...> Wenn das dann auch nicht klappt ist entweder etwas im Studio total> verkonfiguriert oder Dein Tiny85 hat eine Macke ...
kk mache ich.
Und zur Bitmanipulation. Das ist ein Tiny OHNE Debug, wie du dem schon
gezeigtem schaltplan entnehmen kann.
Und das mit der LED WIESO zum T***... ich habe hier ein Oszi stehen wie
ich schon offt schrieb.
demont schrieb:> kk mache ich.> Und zur Bitmanipulation. Das ist ein Tiny OHNE Debug, wie du dem schon> gezeigtem schaltplan entnehmen kann.> Und das mit der LED WIESO zum T***... ich habe hier ein Oszi stehen wie> ich schon offt schrieb.
Ach Leuts:
http://www.mikrocontroller.net/articles/Bitmanipulation
Und das mit der LED ist einfacher als mit Deinem Oszi und Du lernst
gleich noch mehr.
Vielleicht solltest Du erstmal die hiesigen Tutorials durcharbeiten und
den Tiny85 zum LED blinken bringen je nachdem wie Du den Poti
eingestellt hast.
Sowas willst Du ja wohl erreichen ...
Damit bin ich hier auch raus.
Nochmal zusammengefasst:
1) Du schreibst das LED_tiny85.hex von oben ins Flash des tiny85 ( genau
dieses hex-file und kein anderes )
2) Nach dem Schreiben machst du ein Verify; dieser Verify-Vorgang ist
fehlerfrei
3) Danach liest du den Flash-Inhalt aus. Dieser entspricht dem, was du
oben in "chip.hex" gepostet hast
Für mich lässt das nur den Schluss zu, daß du bei einem dieser Schritte
etwas anderes tust.
Da Schritt 2) eigentlich kaum Fehlerpotential beinhaltet: Bei 1) oder 3)
etwas anderes tust.
Da dein tiny nicht tut was er soll, tippe ich auf 1).
Damit bin ich hier auch raus.
cppler schrieb:> demont schrieb:>> kk mache ich.>> Und zur Bitmanipulation. Das ist ein Tiny OHNE Debug, wie du dem schon>> gezeigtem schaltplan entnehmen kann.>> Und das mit der LED WIESO zum T***... ich habe hier ein Oszi stehen wie>> ich schon offt schrieb.>> Ach Leuts:> http://www.mikrocontroller.net/articles/Bitmanipulation> Und das mit der LED ist einfacher als mit Deinem Oszi und Du lernst> gleich noch mehr.> Vielleicht solltest Du erstmal die hiesigen Tutorials durcharbeiten und> den Tiny85 zum LED blinken bringen je nachdem wie Du den Poti> eingestellt hast.> Sowas willst Du ja wohl erreichen ...> Damit bin ich hier auch raus.
sry, der Tag war lang und hatte dies leider vertauscht gehabt.
Und nein sowas muss ich nicht machen. Habe schon lange erfahrung
mit controllern gehabt. Habe auch schon einen voll funktionsfähigen
MP3 Player via Xmega a3 und vs1011 Chip, mit drehencoder gebaut, der
seine Daten etweder von einer SD-Card oder CF-card bekommt. Dabmit
musste ich auch ein FAT schreiben, diese chips konnte ich aber über
JTAG live debuggen, an das letztere mit dem live debuggen hatte ich
gedacht
das du das meinst und habe somit an etwas anderes gedacht.
Sry leute aber ich bin momentan echt nervlich an der Grenze,
ich bin ein guter programmierer und schaltungsentwickler, nur ist diese
Schaltung so Banal und ich habe ja nicht mal ein großen Programm hier in
nutzung, sondern ein einfachen einschalten des Ports. Ich fühle mich
hier sowas von verarscht, von diesem scheiß teil..
Ich brauche den Tiny um ein Poti aus zu lesen und 2 reedkontakte um
eine WS2812 Kette mit 800 LED in Reihe. die 800LEDS in Rheie kann ich
Problemlos ansteuern genauso wie die reedkontakte auslesen, nur hat
der atmega8515 keinen adc :/
katastrophenheinz schrieb:> Nochmal zusammengefasst:> 1) Du schreibst das LED_tiny85.hex von oben ins Flash des tiny85 ( genau> dieses hex-file und kein anderes )> 2) Nach dem Schreiben machst du ein Verify; dieser Verify-Vorgang ist> fehlerfrei> 3) Danach liest du den Flash-Inhalt aus. Dieser entspricht dem, was du> oben in "chip.hex" gepostet hast>> Für mich lässt das nur den Schluss zu, daß du bei einem dieser Schritte> etwas anderes tust.>> Da Schritt 2) eigentlich kaum Fehlerpotential beinhaltet: Bei 1) oder 3)> etwas anderes tust.>> Da dein tiny nicht tut was er soll, tippe ich auf 1).>> Damit bin ich hier auch raus.
Das übernimmt alles das AVR S6, da brauchst du nur noch start mit
debuggen betätigen, und AVR comiliert alles, sendet es zum MC und
verifiziert es.
Und nochmal
ES KLAPPT JA SCHLIEßLICH AUCH ALLES MIT DEM 8515!
habe es auch nochmal versucht wie einer vorher gesagt hat das banale
togglen des ports beim 8515 und JA dort klappt es -.-
demont schrieb:> Sry leute aber ich bin momentan echt nervlich an der Grenze,> ich bin ein guter programmierer und schaltungsentwickler, nur ist diese> Schaltung so Banal und ich habe ja nicht mal ein großen Programm hier in> nutzung
Das Problem ist ganz offensichtlich, daß du nichtmal in der Lage bist,
deine Entwicklungsumgebung korrekt zu benutzen.
Das weist mit Sicherheit nicht auf einen guten Programmierer hin, deine
diesbezügliche Aussage ist also stark zu bezweifeln.
Und was die nervliche Belastung angeht: Klar, es kann schonmal
passieren, daß man sich so verfranst, daß garnix mehr zu gehen scheint.
Aber auch hier wissen erfahrene Programmierer, wie man mit sowas am
besten angeht: Ein schönes Bier trinken, ein paar Seiten Belletristik
lesen, bis die Augen zufallen und dann ein paar Stunden schlafen.
Aufwachen, in Ruhe frühstücken.
Erst dann nochmal anschauen, was man am letzten Abend gemacht hat...
AVR Studio 6.1 hat mich letztes Wochenende auch einen ganzen Abend
gekostet. Es stellte sich heraus, das der Wechsel des Ziel-Kontrollers
im Projekt nicht richtig funktioniert hatte. "Start ohne Debugging" aus
dem Projekt heraus produzierte regelmäßig Mist.
Versuch mal stattdessen, die erzeugte .elf-Datei via Tools->Device
Programming->Memories auf den uC zu laden.
LG, Sebastian
c-hater schrieb:> Und was die nervliche Belastung angeht: Klar, es kann schonmal> passieren, daß man sich so verfranst, daß garnix mehr zu gehen scheint.>> Aber auch hier wissen erfahrene Programmierer, wie man mit sowas am> besten angeht: Ein schönes Bier trinken, ein paar Seiten Belletristik> lesen, bis die Augen zufallen und dann ein paar Stunden schlafen.> Aufwachen, in Ruhe frühstücken.>> Erst dann nochmal anschauen, was man am letzten Abend gemacht hat...
schon geschehen und genau weil selbst das nicht klappte, habe ich mich
an euch gewand.
c-hater schrieb:> Das Problem ist ganz offensichtlich, daß du nichtmal in der Lage bist,> deine Entwicklungsumgebung korrekt zu benutzen.>> Das weist mit Sicherheit nicht auf einen guten Programmierer hin, deine> diesbezügliche Aussage ist also stark zu bezweifeln.
achso also die kompetenz eines Programmieres ist die Qualifikation mit
einer Entwicklerumgebung um zu gehn, kk dann mache ich eine Schulung
über AVR S6 und nenne mich anschließend Profi Programmierer obwohl ich
keine Ahnung von Programmieren habe...
Also echt. Die Entwicklerumgebung ist nur eine Hilfe um das
geschriebende
in einen MC zu bekommen oder Syntaxfehler zu erkennen bzw das
geschriebene
in Maschinencode umzuwandeln. Klar es sind Features und
viele optionen hinzugekommen die hilfe geben, aber Programmierer ist
der,
der:
DEN PROGRAMMCODE SCHREIBT!
cppler schrieb:> Erstelle erstmal ein neues Projekt mit dem Tiny85 als Ziel und einem> komplett neuen Verzeichnis.
so nun auch gemacht mit immer noch dem gleichen Ergebniss
Sebastian Wangnick schrieb:> Versuch mal stattdessen, die erzeugte .elf-Datei via Tools->Device> Programming->Memories auf den uC zu laden.>> LG, Sebastian
Tausend dank Sebastian.
Aber wieso funktioniert die ander vorgehensweise tadellos beim
atmega8515 und nicht mehr beim Tiny?
das müsste doch irgend eine Ursache haben die man beheben kann?
Keine Ahnung was sich da manchmal verklemmt. Bei mir hat zweimaliger
Neustart von AVR Studio geholfen, dann gings auch wieder aus dem Projekt
heraus. Die Idee ein komplett neues Projekt aufzusetzen ist sicher auch
gut.
Und ich war genauso ziemlich am verzweifeln, weil mein Minimalprogramm
(sah so ähnlich aus wie deins) es auch nicht tat.
Ich könnte jetzt auch keine genaue Fehlerbeschreibung an Atmel liefern.
Es scheint nur irgendwie beim Umstellen eines Projekts auf einen
anderen Ziel-Controller manchmal zu haken ...
LG, Sebastian
Sebastian Wangnick schrieb:> Keine Ahnung was sich da manchmal verklemmt. Bei mir hat> zweimaliger> Neustart von AVR Studio geholfen, dann gings auch wieder aus dem Projekt> heraus. Die Idee ein komplett neues Projekt aufzusetzen ist sicher auch> gut.>> Und ich war genauso ziemlich am verzweifeln, weil mein Minimalprogramm> (sah so ähnlich aus wie deins) es auch nicht tat.>> Ich könnte jetzt auch keine genaue Fehlerbeschreibung an Atmel liefern.> Es scheint nur irgendwie beim Umstellen eines Projekts auf einen> anderen Ziel-Controller manchmal zu haken ...>> LG, Sebastian
Und hier ist der Knack Punkt.
Computer Neu gestartet.
AVR Neu gestartet.
Neues Projekt erstellt.
Und dennoch genau dieses Problem :/
lg
demont
Sebastian Wangnick schrieb:> Hast du das neue Projekt in einer neuen Solution erstellt, oder in> der> bisherigen Solution? Vielleicht liegts ja da dran?>> LG, Sebastian
Alles komplett neu an einen anderen Speicherort.
Nun klappt es zwar auf deine Weise aber jedes mal es auf
diese Weise zu machen wäre ein wenig nervig...
Die Frage ist hier, wo liegt nun genau das Problem?
Thread beobachten
Seitenaufteilung abschalten