Hallo,
seit 1 Woche kämpfe ich mit den beiden genannten Prozessoren. ISP ging
erst auch nicht, aber jetzt ist zumindest das ok und ich kann folgendes
kleines Programm laden:
1
#include <avr/io.h>
2
#include <util/delay.h>
3
4
int main() {
5
DDRC = 0x3f;
6
while (1) {
7
PORTC ^= 0x3f;
8
//_delay_ms(5);
9
PORTC ^= 0x3f;
10
}
11
}
Leider liegen die Pins am PortC alle auf gnd. Takt intern oder Quarz
16MHz, beim M168 kann ich den Takt am Ausgang sehen.
Hat jemend eine Idee, warum ein AVR sich so verhält und wie könnte ich
noch prüfen, ob er z.B. intern ständig in reset geht oder das Programm
ordentlich abarbeitet ?
Gruß,
Michael
Schaltplan posten. Die selbe Anweisung zwei mal in die Schleife zu
schreiben macht uebrigens wenig Sinn... Wie hast Du ueberhaupt gemessen,
der Programmcode kann je nach Takt leicht ein Signal von >1MHz an diesem
Port erzeugen.
also das programm wenn es denn richtig geladen wird sollte 100%ig
funktionieren und die pins ca mit der taktfrequenz des avrs toggeln,
also liegts sicher nicht daran, dass du nichts am ausgang siehst.
es wäre hilfreich, wenn du deine schaltung postest.
spontan würde mir einfallen, dass du entweder die fuses falsch gesetzt
hast zB auf externer oszillator, wobei dann das programmieren auch nicht
gehen sollte, oder du hast irrtümlich vergessen den reseteingang auf
high zu ziehen.
weitere schätzungen sind nicht ohne deiner schaltung möglich denke ich
;)
lg,
gerald
> also das programm wenn es denn richtig geladen wird sollte 100%ig> funktionieren, also liegts sicher nicht daran.
Funktionieren wirds schon, nur wirds (wahrscheinlich) nicht das
gewünschte Ergebnis liefern.
gast wrote:
>> also das programm wenn es denn richtig geladen wird sollte 100%ig>> funktionieren, also liegts sicher nicht daran.>> Funktionieren wirds schon, nur wirds (wahrscheinlich) nicht das> gewünschte Ergebnis liefern.
das gewüschte ergebnis ist die pins auf portc toggeln zu lassen, und das
macht das programm, also liegts nicht daran, es liegt eher an der
schaltung in der der atmega8 verbaut ist oder an einer falschen fusebit
konfiguration.
Hallo,
Schaltungposten hilft nur wenig, weil da ist nur 5V und GND, sowie 33k
von VCC an 100nF, dann 10k an Reset. Und ob ich das richtg verdrahtet
habe ? Es sind 2 unterschiedliche Boards, an einem lief schonmal ein M8
mit einem LCD. Reset ist nach dem Einschalten auf +5V.
Ach so, zu schnell kann das Programm nicht sein, schaut mal das
auskommentierte delay an.
Und 2x der gleiche Code hat was mit dem Setzen von 2 Breakpoints im
Simulator zu tun.
Clock ist wurst, ich sehe den Takt per CKOUT am Pin 14 von 1 bis 18,432
MHz.
Gibt es sowas wie eine Master-Port-Off ?
Ich fühl mich wie blöd, das eine Board lief doch schon mal und die
Prozessoren habe ich vorgestern neu bsorgt.
Gruß,
Michael
Michael Appelt wrote:
> Hallo,>> Schaltungposten hilft nur wenig, weil da ist nur 5V und GND, sowie 33k> von VCC an 100nF, dann 10k an Reset.
Sehr aufschlussreich... Warum haengst Du 33k an VCC, dass das nicht
funktionieren kann sollte klar sein, oder? Nen bissel mehr als 100uA
braucht Dein Mega schon im Betrieb.
Naja ohne einen anstaendigen Schaltplan kann ich keine Aussage treffen.
Entweder liegt der Fehler in der Schaltung oder irgendwo im Aufbau.
Vielleicht leiht mir ja jemand sein schwarzes Auge...
Hallo,
Schaltplan ist nicht, es ist ein Lochrasteraufbau, GND an GND und AGND,
VCC an VCC, AVCC und AREF, und halt RC-Glied an Reset.
Die pins habe ich schon 30mal durchgemessen, aber irren kann ich mich
trotzdem.
Alle pins sind offen auf Stiftleiste geführt, Pins sind zum Nachbarpin
isoliert etc.
Trotzdem fragt mich bitte weiter dumme fragen, irgendwann kommen wir
drauf.
ISP funktioniert ja auch...
Gruß,
Michael
wenn alles, so wie du sagst, richtig aufgebaut ist dann sag ich dir dass
es auch funktioniert.
wenn dein richtiger aufbau aber vielleicht doch falsch ist dann kann dir
das niemand sagen wenn du kein foto von dem ganzen machst und hier
hochlädst.
trotzdem noch eine schätzung: bist du dir sicher den code auch für den
atmega8 kompiliert zu haben ? also dem compiler gesagt zu haben das
hexfile für den atmega8 zu generieren ?
lg,
gerald
ps: ich stelle keine dummen fragen.
Mit raten hab ich's nicht so. Entweder Du stellst die noetigen
Informationen in Form von Schaltplan und einem guten Bild vom Aufbau
oder Du suchst den Fehler halt selbst. Ist dann Deine Zeit.
Hallo,
also ich habe 2 AVR-Programme für M8 und M168.
Habe beide programmiert und vor der Übertragung die Signatur nochmal
ausgelesen.
Jetzt toggle ich alle freien Pins und nix rührt sich. Trotzdem
funktioniert ISP, es kann also z.B. kein Kurzschluss/Unterbrechung am
MISO- oder MOSI-Pin sein oder ein zerschossener Treiber.
Wie siehts denn mit SLEEP etc aus ? Kann es sein, daß der sich schlafen
legt, wenn kein sei() ausgeführt wird ?
Gruß,
Michael
moin
immer sauber
#include <inttypes.h>
#include <avr/io.h>
#ifndef F_CPU
#define F_CPU 8000000UL /* Quarz/InternerOz mit ,,Mhz */
#endif
#include <util/delay.h> /* definiert _delay_ms() ab avr-libc Version
1.2.0 */
Cpu freq. vor dem Inlude von delay.h definieren - :-) auch wenn du es
nicht benutzt im moment
und vielleicht mal die Ports richtig definieren ( auch wenns schweer
fällt )
#define OC1A_PIN PB1 // OC1A pin (ATmega8 use PB1)
#define OC1A_DDR DDRB // OC1A DDR (ATmega8 use DDRB)
zBsp. so
und wenn es dann nicht geht vielleicht mal aus der while ne leere for
machen ' for (;;) '
und das void nicht vergessen
int main(void)
{
lese dir doch einfach mal hier das c-tutorial durch
mfg
ein C-anfänger
Hallo,
evtl habe ich vergessen zu sagen, daß der AVR-Simulator mir die Ports
richtig toggelt.
Was die Definitionen anbelangt: ich programmiere hauptberuflich seit
1970, aber wenn garnix mehr funktioniert, dann lasse ich alles weg, was
fehlerhaft sein könnte, also auch die Definitionen.
BTW habe ich bereits mit dem M8 auf dem gleichen Board ein 4x40-er LCD
zum Laufen gebracht sowie einen preemptiven Multitaskingkernel auf dem
M32 programmiert....ich gehe also von einem Idiotenfehler meinerseits
aus, irgendwas völlig blödes, aber ich komm seit Jahresanfang nicht
dahinter.
Immerhin veranlasst mich jedes Eurer Postings zu weiteren Tests, dafür
mein Dank.
Gruß,
Michael
pillepalle wrote:
> ach , fast vergessen>> ziehst du den ISP Stecker ab oder bleibt der Programmer drann> dann kann es ja wohl sein das der Resettpin dauernd auf low liegt
Habe nochma probiert, ISP abgezogen, PWROFFON und Reset mit Taster sowie
Kontrolle am Oszi....nix, der tut nix.
Gruß,
Michael
Hallo,
Ihr habt mich auf eine Idee gebracht: falls ich den Code für den
falschen AVR brenne, setzt das Programm die falschen Ports und ich sehe
nix.
So eine Erklärung habe ich gesucht, ich werds bis morgen weiter
verfolgen....
Gruß,
Michael
Hallo,
ich hab es gefunden :-))
Der Dialog zum Brennen des Flashs hatte die falsche Hexdatei aus einem
völlig anderen Projekt mit einem M16.
Irgendwie kann ich mich nicht daran gewöhnen, daß diese Studio in jeden
Bereich neu konfiguriert werden muss. Das ist sicher eher keine
Integration der einzelnen Werkzeuge, aber für 0€ ist es trotzdem sehr
brauchbar, und vielleicht benutze ich es ja auch noch falsch.
Eure Fragen haben mir geholfen, alles nochmals allseitig zu überprüfen.
Das geht mir oft so, wir reden alle in meiner Gruppe miteinander, falls
wir nicht weiterkommen, und meist kommen wir beim Fragen dann selbst auf
die Lösung. Am schlimmsten ist das einsame Brüten mit dem Debugger...
Gruß,
Michael
PS: BTW programmier ich beruflich erst seit 1977...
Thread beobachten
Seitenaufteilung abschalten