Hallo
das nachfolgende Programm funktioniert nur eingeschränkt:
1
#include<avr/io.h>
2
#include<util/delay.h>
3
4
intmain(void)
5
{
6
DDRA=0xFF;
7
while(1)
8
{
9
PORTA=0xFF;
10
_delay_ms(1000);
11
PORTA=0x00;
12
_delay_ms(1000);
13
};
14
}
Ich hatte erwartet, daß der Port A jeweils eine Sekunde high oder low
ist, was aber keineswegs geschieht. Vielmehr ist eine Kontroll-LED fast
immer hell und geht im Sekundentakt nur ganz kurz aus.
Wenn ich aber
- die beiden PORTA-Zeilen vertausche
o d e r
- die untere delay-Zeile an den Beginn der while-Schleife verschiebe,
dann blinkt es es erwartungsgemäß.
Hat jemand eine Erklärung für dieses eigenartige Verhalten?
Gruß
Egon
Richard B. schrieb:
> Guck dir mal die delay.h an.>> Da steht sowas drin:>> The maximal possible delay is 262.14 ms / F_CPU in MHz.>>> ich vermute das ist das Problem.
Bei der neuesten WinAVR Version geht das aber.
Richard B. schrieb:
> Guck dir mal die delay.h an.>> Da steht sowas drin:>> The maximal possible delay is 262.14 ms / F_CPU in MHz.>>> ich vermute das ist das Problem.
Ja, vorallem steht da drin:
>> The maximal possible delay is 262.14 ms / F_CPU in MHz.>>>> When the user request delay which exceed the maximum possible one,>> _delay_ms() provides a decreased resolution functionality. In this>> mode _delay_ms() will work with a resolution of 1/10 ms, providing>> delays up to 6.5535 seconds (independent from CPU frequency).
Richard B. schrieb:
> Guck dir mal die delay.h an.>> Da steht sowas drin:>> The maximal possible delay is 262.14 ms / F_CPU in MHz.>>> ich vermute das ist das Problem.
Leider nicht, denn
1. bisher habe ich an anderer Stelle mit z.B. 5000 ms keine Probleme
gehabt (vielleicht neuere WinAVR-Version)?
2. ich habe probeweise die Zeile delay_ms(1000) ersetzt durch fünf mal
hintereinander delay_ms(1000) - gleicher Effekt.
@Holger
Ein Watchdog ist nicht eingeschaltet (was ich gepostet hatte, ist das
ganze Programm). Außerdem mußte er ja auch ansprechen, wenn ich, wie
beschrieben, die PORT-A-Zeilen vertausche.
mfg
Egon
Egon Müller schrieb:
> Ein Watchdog ist nicht eingeschaltet (was ich gepostet hatte, ist das> ganze Programm).
Den kann man auch per Fuse einschalten.
> Außerdem mußte er ja auch ansprechen, wenn ich, wie> beschrieben, die PORT-A-Zeilen vertausche.
Ja. Aber das kann dennoch zu Blinkeffekten führen.
Gib mal statt 0x00/FF einen Zähler ab 1 aufwärts auf die LEDs. Dann
siehst du, ob der auch zählt oder immer startet und deshalb 1 kommt.
A. K. schrieb:
> Egon Müller schrieb:>>> Ein Watchdog ist nicht eingeschaltet (was ich gepostet hatte, ist das>> ganze Programm).>> Den kann man auch per Fuse einschalten.
WDTON ist aus
>>> Außerdem mußte er ja auch ansprechen, wenn ich, wie>> beschrieben, die PORT-A-Zeilen vertausche.>> Ja. Aber das kann dennoch zu Blinkeffekten führen.>> Gib mal statt 0x00/FF einen Zähler ab 1 aufwärts auf die LEDs. Dann> siehst du, ob der auch zählt oder immer startet und deshalb 1 kommt.
Ja, er zählt hoch.
Sehr eigenartig: der häßliche Effekt tritt auf, wenn ich in der ersten
PORT-A-Zeile schreibe PORTA = 0xFF (oder =255). Schreibe ich PORTA =
254 (oder weniger), ist alles in Ordnung.
Der Zusammenhang zwischen dem Port und dem nachfolgenden Delay ist mir
unerklärlich
Ist der oben zitierte Code
(Beitrag "Spuk oder Programmfehler?") auch wirklich
GENAU DER CODE, welcher SO nicht funktioniert, oder hast du deinen Code
nur für dein Posting zusammgengestutzt, ohne diesen nochmals separat zu
testen?
Welchen Controller verwendest du? Evtl. könnten wir den Code dann mal
bei uns auf nem Controller testen....
Magnus Müller schrieb:
> Ist der oben zitierte Code> (Beitrag "Spuk oder Programmfehler?") auch wirklich> GENAU DER CODE, welcher SO nicht funktioniert, oder hast du deinen Code> nur für dein Posting zusammgengestutzt, ohne diesen nochmals separat zu> testen?>> Welchen Controller verwendest du? Evtl. könnten wir den Code dann mal> bei uns auf nem Controller testen....
Das ist der ganze Code,
der Controller ist ein Atmega 644P mit 16-MHz-Quarz,
benutzt wird WinAVR090313.
Der Code dient dazu, bunte Adern, die über mehrere Stecker laufen, auf
ihre Zuordnung zu den Ports nochmals sicherheitshalber zu kontrollieren.
Das ist zwar inzwischen geklärt, aber nun würde ich gern den zufällig
entdeckten Effekt verstehen.
mfg
Egon
A. K. schrieb:
> Dann käme noch die Hardware in Frage. Kerkos vergessen, AVCC nicht> angeschlossen, ...
Die Hardware ist vielfach kontrolliert und getestet (nicht von mir!), es
handelt sich um Uli Radigs Webserver, auf dem derzeit dieses
Miniaturprogramm betrieben wird, um eine zusätzliche Platine zu
integrieren.
Ich gehe mal davon aus, daß Ulis Webmodul in Ordnung ist und auf meiner
Platine gibt es nur einige Stecker und eine LED samt Vorwiderstand.
Daran dürfte es nicht liegen.
Egon Müller schrieb:
> Die Hardware ist vielfach kontrolliert und getestet (nicht von mir!), es> handelt sich um Uli Radigs Webserver
Falls es die Platine von mikrocontroller.com sein sollte: Just bei der
fehlen die Kerkos zwischen (A)VCC und GND.
A. K. schrieb:
> Egon Müller schrieb:>>> Die Hardware ist vielfach kontrolliert und getestet (nicht von mir!), es>> handelt sich um Uli Radigs Webserver>> Falls es die Platine von mikrocontroller.com sein sollte: Just bei der> fehlen die Kerkos zwischen (A)VCC und GND.
Ist nicht von mikrokontroller.com, sondern von Ulrich Radig und das ist
am AVR und den übrigen IC's mit etlichen 100-nF-Kondensatoren bestückt
http://ulrichradig.de/ unter ETH_M32_EX.
holger schrieb:
>>Das ist der ganze Code,>> Poste dein Projektverzeichnis als ZIP Archiv.
Für dieses Miniatur- und Hilfsprogramm gibt es kein Projekt, ich
kompiliere es innerhalb von pn2 und schicke es manchmal mit AVRStudio
oder direkt aus pn2 zum Controller. Ein Makefile könnte ich noch bieten
und ein Hexfile, meinst Du das? Sonst existiert nichts weiter.
Gruß
Egon
>Ein Makefile könnte ich noch bieten>und ein Hexfile, meinst Du das? Sonst existiert nichts weiter.
Poste mal den kompletten Ordner, in dem das Source-File und das makefile
stecken, am einfachsten zusammengezippt.
Oliver
Egon Müller schrieb:
> A. K. schrieb:>> Egon Müller schrieb:>>>>> Ein Watchdog ist nicht eingeschaltet (was ich gepostet hatte, ist das>>> ganze Programm).>>>> Den kann man auch per Fuse einschalten.>> WDTON ist aus
Könntest du bitte genau formulieren, welchen Zustand WDTON gerade hat?
Ich weiß, klingt blöde, aber das ist bei den Fuses ja immer noch zehnmal
umgedreht :-)
Oliver schrieb:
>>Ein Makefile könnte ich noch bieten>>und ein Hexfile, meinst Du das? Sonst existiert nichts weiter.>> Poste mal den kompletten Ordner, in dem das Source-File und das makefile> stecken, am einfachsten zusammengezippt.>> Oliver
Hier mein allererster Versuch, ein zip-Archiv zu erstellen, hoffentlich
ist er gelungen.
@Sven
in AVRStudio ist bei den Fuses k e i n Häkchen bei WDTON gesetzt.
Gruß
Egon
>Hier mein allererster Versuch, ein zip-Archiv zu erstellen, hoffentlich>ist er gelungen.
Perfekt.
Kannts du jetzt noch den Ordner mirtPORTA=255; also der Version, die
anscheinend nicht funktioniert, hier einstellen?
Oliver
Oliver schrieb:
>>Hier mein allererster Versuch, ein zip-Archiv zu erstellen, hoffentlich>>ist er gelungen.>> Perfekt.>> Kannts du jetzt noch den Ordner mirtPORTA=255; also der Version, die> anscheinend nicht funktioniert, hier einstellen?>> Oliver
Es i s t der Ordner (umbenannt, weil ich die übrigen Exercitien
separat weiterführen möchte).
Die im zip-Archiv enthaltene Version Porttest.c ist die eigenartige
Version:
schreibe ich bei PORTA = 254, blinkt es erwartungsgemäß,
schreibe ich = 0xFF oder = 255, dann geht es bei mir schief.
Vielleicht sollte ich noch hinzufügen:
Wenn ich in der mißlungenen Schreibweise (PORTA = 0xFF) die unterste
Delayzeile ganz nach oben verschiebe, dann ist es wieder so, wie man es
sich wünscht.
mfg
Egon
>schreibe ich = 0xFF oder = 255, dann geht es bei mir schief.
Eben. Genau diese Version von deinem Computer, mit deinem Compiler
compiliert, hätte ich gerne (denn, wenn ich das bei mir kompiliere,
funktionieren beide Varianten. Garantiert).
Oliver
Es reicht auch, wenn Du das "255", nicht funktionierende Hex File
reinstellst.
Das wäre schon interessant was da an anderem Code erzeugt wird, zuletzt
eingestellter Code mit "254" ist jedenfalls einwandfrei, nachfolgend
übersetzt:
Ein neuer Versuch:
nicht funktionierende Version Porttest.c (mit PORTA = 255), kompiliert
mit WinAVR 090313;
dazu alle erzeugten Dateien (incl. Hex-Datei) und außerdem
die im Unterverzeichnis .dep angelegte Datei (umbenannt in
dep.Porttest.o.d).
Das Ganze als zip-Datei hier angehängt.
mfg
Egon
Die beiden Hex-Files unterscheiden sich nur in dem Wert, der in
PORTA geschrieben wird:
1
< :100090000C9400008FEF81B94EEF20E931E042B9B6
2
^ ^ -> 0xFE = 254
3
---
4
> :100090000C9400008FEF81B94FEF20E931E042B9B5
5
^ ^ -> 0xFF = 255
Das kann also kaum die Ursache für das unterschiedliche Timing bei der
Ausführung sein, es sei denn, es liegt ein Hardwarefehler im Controller
oder der umliegenden Schaltung vor. Hast du schon einmal einen anderen
Controller ausprobiert?
Nachtrag: Das Register R20, in dem der Wert 255 bzw. 254 gehalten wird,
wird nur zur Ausgabe an PORTA und nirgends sonst verwendet. Dass die
Zeitschleifen unterschiedlich lang laufen, kann also nicht mit einem
Compiler- oder Programmierfehler zusammenhängen.
@yalu,
Der erzeugte Assemblercode, bzw. das Hexfile ist einwandfrei. Laufen
auch Beide im Simulator durch.
Der einzige Unterschied besteht aus:
1
SER R20
statt
1
LDI R20,0xFE
Und das ist so korrekt, damit wird das R20 Register zur Ausgabe auf
PortA gesetzt. Das Timing ist exakt gleich.
@Egon,
Verhalten muss durch die Hardware begründet sein, mglw. defekter
Controller. Was hängt alles an PortA.0 ? Eine Verbindung die dieses
Verhalten, vielleicht einen Reset auslösen kann ? Kannst Du einen
Schaltplan posten ?
MWS schrieb:
> Der einzige Unterschied besteht aus:>
1
> SER R20
2
>
> statt>
1
> LDI R20,0xFE
2
>
Das ist beides ein LDI. SER ist nur Syntactic Sugar.
Mögliche Fehlerquellen:
-- Watchdog
-- Defekter µC
-- Unsaubere Spannungsverorgung
(schwingt/sackt ein/Transienten bei Belastung)
-- Es kommt zu RESETs (zB durch Transienten bei Belastung)
Gibt es Abblockkondensatoren?
Wie wird VCC gemacht?
Wie ist RESET beschaltet? (100nF nach GND und 10kΩ nach VCC?)
Johann
Ich habe mir mal das Layout angesehen. Der Abblockkondensator an AVCC
ist recht ungünstig platziert. Löte doch mal einen 100nF an der
Unterseite direkt an die Pins 30 und 31 des µC.
Nachtrag zu meinem Post oben:
Mit dem Abblockkondensator am "normalen" VCC sieht es kaum besser aus.
Also auf der Rückseite auch noch gleich einen 100nF zwischen Pin 10 und
11 setzen.
> Das ist beides ein LDI. SER ist nur Syntactic Sugar.
Das ist aber schön. Da SER die Ausgabe des AVR Studios war, hatte ich
allerdings keinen Grund dies umzudeuten.
Ändert nix daran daß der Code einwandfrei arbeitet und somit PortA.0
direkt oder indirekt Auslöser für dieses Problem ist.
MWS schrieb:
>> Das ist beides ein LDI. SER ist nur Syntactic Sugar.>> Das ist aber schön. Da SER die Ausgabe des AVR Studios war, hatte ich> allerdings keinen Grund dies umzudeuten.>> Ändert nix daran daß der Code einwandfrei arbeitet und somit PortA.0> direkt oder indirekt Auslöser für dieses Problem ist.
A0 war früher unbeschaltet, als es falsch lief, jetzt ist es SCL für
einen PCF8574A mitsamt einem 10-k nach Plus (läuft immer noch falsch).
Wenn ich wieder dazu komme, werde ich mir den mal einen anderen
Prozessor einsetzen und sehen, ob ich, wie Stefan schreibt, da und dort
noch Kondensatoren unterbringen kann.
Hat mal jemand das "Programm" auf einem anderen Prozessor laufen lassen
- gibt es da auch Probleme?
mfg
Egon
>A0 war früher unbeschaltet, als es falsch lief, jetzt ist es SCL für>einen PCF8574A mitsamt einem 10-k nach Plus (läuft immer noch falsch).
Na prima. Etwas funktioniert nicht, und dann wird nochwas angeschlossen.
>Wenn ich wieder dazu komme, werde ich mal einen anderen Prozessor>einsetzen
Tu das.
>Hat mal jemand das "Programm" auf einem anderen Prozessor laufen lassen>- gibt es da auch Probleme?
Wozu? Das Programm kann nur richtig laufen. Das der AVR-GCC
bei so einem simplen Programm Fehler macht dürfte unglaublich
unwahrscheinlich sein.
@Egon,
Ich hatte beide Hex Files in den Simulator des AVR Studios geladen und
dort simuliert. Beide Versionen laufen absolut einwandfrei.
Zumal unterscheidet sich die funktionierende Version von der nicht
funktionierenden nur darin, daß der PortA.0 nicht gesetzt wird, sonst
sind sie absolut identisch.
Das ist eindeutig ein Problem der HW.
holger schrieb:
>>A0 war früher unbeschaltet, als es falsch lief, jetzt ist es SCL für>>einen PCF8574A mitsamt einem 10-k nach Plus (läuft immer noch falsch).>> Na prima. Etwas funktioniert nicht, und dann wird noch was angeschlossen.>
Ist unproblematisch, weil das Webmodul nur wegen der bequemen Anschlüsse
vorübergehend benutzt wird.
Ich glaube, der arme Port A.0 wird zu unrecht verdächtigt. Das mißliche
Verhalten kann auch unterdrückt werden, wenn man schreibt
PORTA = 253; oder = 251;, also den A.0 beibehält und andere Ports
ausschaltet. Sogar PORTA = 1 ist gut. Also nichts gegen den A.0!
Also doch Spuk?
mfg
Egon
MWS schrieb:
> PortA.0 geht an SD0 der Netzwerkkarte, steck mal die Karte aus und> probier's nochmal.
Also, ich habe mir Uli Radigs Schaltplan von oben bis unten
durchgesehen, da gibt es keine Verbindung von PORTA.0 zu dem ENC28... ,
einzig und allein zu einem Stecker, wo analoge oder digitale Sachen
angeschlossen werden können (der für meine derzeitigen Exercitien so
bequem ist).
mfg
Egon
Prinzipiell werden Atmels Megas so gefertigt, daß man alle Portpins
gleichzeitig einschalten kann. :D
Wenn's bei Deinem anders ist, dann ist's wohl eine Sonderversion.
Aber ist halt müssig weiter eine SW Fehlfunktion zu unterstellen, wenn
man anhand des Compilats beweisen kann, daß es die SW auf keinen Fall
sein kann.
Der PortA.0 wurde nur aufgrund der von Dir gegebenen Information
verdächtigt.
Entweder ist in Deiner Schaltung der Wurm drin, oder im ATMega. Da Du
bereits Probleme hattest, kennst Du nun möglicherweise den Grund dafür.
Da Du keinen Schaltplan angehängt hast, habe ich mich aus dem Internet
bedient und dort eine Version gefunden, bei der PortA.0 mit der
Datenleitung der Netzwerkkarte verbunden war.
Falls Du einen anderen Schaltplan hast, dann häng ihn an und man kann
einen Blick drauf werfen.
Ich habe mir den Resetpin mit dem Oszi angesehen, der hat unentwegt
high-level, es sind keinerlei Einbrüche zu erkennen - während bei
PORTA=0xFF das incriminierte Verhalten zu beobachten ist.
mfg
Egon
MWS schrieb:
> Da Du keinen Schaltplan angehängt hast, habe ich mich aus dem Internet> bedient und dort eine Version gefunden, bei der PortA.0 mit der> Datenleitung der Netzwerkkarte verbunden war.>
Hallo MWS
Der Schaltplan ist bei
http://ulrichradig.de/ unter ETH_M32_EX
zu finden. Eine Netzwerkkarte gibt es da gar nicht.
Vielleicht sollte ich mir einfach einen anderen Controller beschaffen,
einsetzen und abwarten, was passiert.
mfg
Egon
Wenn der Atmel aus irgendwelchen Gründen abschmiert wirst Du nix am
Resetpin messen können.
Wenn hier was blinken würde, dann ist der Wurm drin:
1
#include<avr/io.h>
2
#include<util/delay.h>
3
4
intmain(void)
5
{
6
DDRA=0xFF;
7
PORTA=0x00;
8
_delay_ms(1000);
9
while(1)
10
{
11
PORTA=0xFF;
12
_delay_ms(1000);
13
};
14
}
Wenn da nix blinkt, dann mal vor der Schleife den Port setzen und in der
Schleife löschen, schauen was passiert.
Ah, Du meist das AVR Webmodul, als Webserver bezeichnet Ulrich Radig
etwas anderes. Ja, Du hast recht, am PortA hängt nix dran.
Alle Pins durchgemessen, kein Schluss untereinander oder gegen Minus
oder Plus ?
Ich kann Dir nur sagen, daß der Assemblercode so einfach und auch
erkennbar einwandfrei ist, daß ein normal funktionierender AVR ihn
garantiert verarbeiten würde.
Probier' mal PortD anzusteuern, der ist auch an SV1 rausgeführt.
Wobei RXD/TXD PortD.0 & PortD.1 sind. Solange Du das UART nicht
einschaltest, arbeitet der als normaler Port. Wenn ich nix im Schaltplan
übersehen habe, dann sind die 2 Pins nur noch mit der Buchse JP2
verbunden, aber mit nix sonst. Also würd' sich der Port zum Testen
Deines kurzen Codes eignen.
Noch ein Tip, wenn PortD einwandfrei funktioniert, dann häng dort an die
Pins 0-4 fünf LED's ran und schreib das Register MCUSR gleich zu Anfang
Deines Programmes an den Port raus und lösch dann MCUSR.
Sollte der Atmel ungewollt in den Reset gehen, so siehst Du an den LED's
den Grund für den Reset. Datenblatt ATM644P, Seite 57, MCU Status
Register.
MWS schrieb:
> Wenn der Atmel aus irgendwelchen Gründen abschmiert wirst Du nix am> Resetpin messen können.>> Wenn hier was blinken würde, dann ist der Wurm drin:>
1
>#include<avr/io.h>
2
>#include<util/delay.h>
3
>
4
>intmain(void)
5
>{
6
>DDRA=0xFF;
7
>PORTA=0x00;
8
>_delay_ms(1000);
9
>while(1)
10
>{
11
>PORTA=0xFF;
12
>_delay_ms(1000);
13
>};
14
>}
15
>
> Wenn da nix blinkt, dann mal vor der Schleife den Port setzen und in der> Schleife löschen, schauen was passiert.>
Es blinkt nichts!
Wenn ich den Port v o r der Schleife setze kommt es darauf an:
PORTA = 255 der alte Zustand
PORTA = 253 einmal kurz hell, dann dunkel.
Bis morgen
Egon
Sehr eigenartig. Aber da die Led die Zeit des Delays hell ist, scheint
erst das Rücksetzen des Ports einen Reset auszulösen.
Probier mal die Hex Datei im Anhang, ist mit Bascom erstellt. Hab' mir
den Assemblercode daraus angesehen, es sind einige Unterschiede zum GCC
Code vorhanden, hauptsächlich wird ein Watchdogreset am Start
ausgeführt, sowie alle Flags des MCUSR gelöscht.
Ein weiterer Unterschied ist, daß Bascom RETIS's in die Interrupttabelle
reinschreibt. Schützt eigentlich nur vor freigegebenen Int's bei nicht
definierten ISR's. Aber vielleicht wird durch einen HW Defekt ein
Interrupt ausgelöst, der dann beim GCC ins Nirvana führt.
Aber: Versuch macht kluch :D
Sven P. schrieb:
> Könntest du bitte genau formulieren, welchen Zustand WDTON gerade hat?> Ich weiß, klingt blöde, aber das ist bei den Fuses ja immer noch zehnmal> umgedreht :-)
Zehnmal invertiert = Originalzustand :-)
> Es blinkt, etwa im Sekundentakt.
Das sollte es auch, das war Dein Blinkprogramm nur in Bascom.
Füg' mal ganz zu Anfang Deines Programmes das hier ein:
1
asmvolatile("wdr");
2
MCUSR&=0xF7;
Bin mir nicht sicher, ob die C-Syntax für die Assembleranweisung so
richtig ist, gibt aber sicher Mitschreiber hier die mich dann
verbessern.
Diese Sequenz baut Bascom ganz zu Anfang ein, sonstiger gravierender
Unterschied zu GCC ist wie bereits gesagt nur das Besetzen der
Interruptvektortabelle mit RETI's um wildgewordene
Interruptanforderungen heimzuschicken.
Noch zwei weitere mögliche Fehlerursachen:
- Die Fuses für die Takterzeugung sind falsch gesetzt, so dass der
Quarzoszillator zwar an-, aber nicht zuverlässig weiterläuft. Du
kannst ja mal alle aktuellen Fuse-Einstellungen posten, vielleicht
sind auch noch weitere Verdächtige dabei.
- Die Versorgungsspannung ist nicht angeschlossen oder instabil. Dann
nimmt sich der Controller den Strom möglicherweise woanders her, z.B.
aus den Signalleitungen eines angeschlossenen ISP-Programmieradapters.
Er läuft dann zwar, aber mehr schlecht als recht. Am besten misst du
die Spannung mit dem Oszi direkt an den VCC- und GND-Pins des
Controllers.
yalu schrieb:
> Noch zwei weitere mögliche Fehlerursachen:>> - Die Fuses für die Takterzeugung sind falsch gesetzt, so dass der> Quarzoszillator zwar an-, aber nicht zuverlässig weiterläuft. Du> kannst ja mal alle aktuellen Fuse-Einstellungen posten, vielleicht> sind auch noch weitere Verdächtige dabei.>
s.o. Das roten Zeichen an SPIEN kann ich mir zwar nicht erklären, es ist
aber seit Anschluß des ISP-Programmers vorhanden
> - Die Versorgungsspannung ist nicht angeschlossen oder instabil. Dann> nimmt sich der Controller den Strom möglicherweise woanders her, z.B.> aus den Signalleitungen eines angeschlossenen ISP-Programmieradapters.> Er läuft dann zwar, aber mehr schlecht als recht. Am besten misst du> die Spannung mit dem Oszi direkt an den VCC- und GND-Pins des> Controllers.
Den Effekt hatte ich mal nach einem Sicherungsfall. Aber hier ist nichts
anderes dran und die Spannung am Vss-Pin ist stabil ohne Einbrüche - mit
und ohne ISP-Programmer
Sven P. schrieb:
> Hm, was die Außenbeschaltung des Ports angeht: Entsteht da vielleicht> bei ungünstiger Kombination ein Kurzschluss?
Ich benutze nur eine einzige LED mit Vorwiderstand, die ich je nach
Bedarf manuell von Port umstecke.
Egon
Die aktuellen Fuse-Einstellungen sind fast ok: Die Fuses für die
Takterzeugung stehen nach Datenblatt auf
CKSEL3..1=111: low power crystal osziollator, 8-16MHZ
CKSEL0=1, SUT1..0=00: ceramic resonator, slowly rising power,
start-up time 1K CK, additional delay 14CK+65ms
(AVR-Studio zeigt "Crystal" an, aber dem
Datenblatt würde ich eher trauen)
Die Start-up-Time von 1K CK ist für einen Resonator richtig, für einen
Quarz werden aber 16K CK, also CKSEL0=1 und SUT1..0=11 empfohlen. Das
erklärt zwar die Fehlfunktion nicht, da dadurch nur dem Oszillator
lediglich mehr Zeit zum Einschwingen gegeben wird, trotzdem würde ich es
ändern.
16MHz ist die maximale Frequenz, für die der Low-Power-Modus des
Oszillators verwendet werden kann. Vielleicht hast du einen komischen
Quarz erwischt, der lieber im Full-Swing-Modus schwingt. Dieser wird
CKSEL3..1=011 aktiviert und reicht bis 20MHz, so dass noch etwas mehr
Luft nach oben bleibt.
Die anderen Einstellungen sind ok.
Die Fuse-Einstellungen für Pessimisten wäre also
extended: 0xFF
high: 0xD9
low: 0xF7 <- geändert, bisher 0xCF
Ich habe zwar keine allzu große Hoffnung, dass sich dadurch etwas
ändert, aber ein Versuch ist es wert.
Thread beobachten
Seitenaufteilung abschalten