Brown Out

Neulings-Fragen zu Spannungs-Unterbrechungen

Pedro Veloceros
 
Avatar
 
Betreff:

Brown Out

 · 
Gepostet: 31.01.2011 - 22:29 Uhr  ·  #1
Hallo an das E-Lab-Forum,

es geht um eine Schaltung mit einem Tiny44. Diese Schaltung wird durch ein- / ausstecken eines Akku-Kabels in/außer Betrieb genommen. Dabei kommt es beim Inbetriebnehmen kurzzeitig zu ungewollten Programmzuständen.

Folgende für Euch sicher einfache Fragen treiben mich dazu um:
1. Ist "Brown Out" der richtige Ausdruck für den Spannungsabfall beim Abklemmen der Versorgungsspannung? Ist es dann richtig, einen "BOD"-Level zu setzen? Ich habe das so gemacht, allerdings ohne eine Verbesserung zu erzielen:
Code

Define_Fuses
  LockBits0 = [];
  FuseBits0 = [];
  FuseBits1 = [BODLEVEL0, BODLEVEL2];
  FuseBits2 = [];

2. Ist es für einen funktionierenden Brown Out erforderlich, schaltungstechnisch eine Kurzzeit-Spannungsversorgung bereitzuhalten. Wie setzt man das praktisch um?

Danke für Eure Hilfe
Pedro
Gunter
Administrator
Avatar
Geschlecht:
Herkunft: Frankfurt Main / Germany
Beiträge: 1697
Dabei seit: 02 / 2003
Betreff:

Re: Brown Out

 · 
Gepostet: 31.01.2011 - 23:54 Uhr  ·  #2
Hi Pedro,

Du musst bei Define_Fuses die aktiven Fuses angeben, also
die Fuses die binär 0 sein sollen.
Deine BOD FuseBits1 sind aber xxxx x010 und das ist "reserved"!
Dein Absicht war wohl:
FuseBits1 = [BODLEVEL1]; // BOD Fuses = 101

BOD Level Fuses setzen ist schon OK (und beim Tiny44 hinreichend),
um den BOD zu aktivieren (der hat keine BODen-Fuse).
Eine Spannungsüberbrückung ist aus diesem Grund nicht notwendig.
Dem BOD ist "egal" woher die Spannung kommt.

Zitat
Dabei kommt es beim Inbetriebnehmen kurzzeitig zu ungewollten Programmzuständen.

Wenn die Korrektur nicht hilft und machbar, würde ich direkt am Anfang ein
mDelay(100) ... mDelay(500) einfügen.
Bis dahin sollte dann die Versorgungsspannung stabil sein.

Gruß
Gunter
Pedro Veloceros
 
Avatar
 
Betreff:

OK, so gehts

 · 
Gepostet: 01.02.2011 - 21:03 Uhr  ·  #3
Hallo Gunther,

vielen Dank für deine schnelle und verständliche Erklärung. Ja, die FuseBits1 hatte ich verkehrt herum gesetzt. Hab ich korrigiert sowie den mdelay(500) am Anfang eingefügt - jetzt funktioniert es wohl.

Kleine Nebenfrage: sollte ich jetzt die FuseBits erkennen können im Programmer-Menü > Options > Programmer Options? Ich hätte hier beim Auslesen entsprechende Haken erwartet, sehe aber keine.

Danke nochmal und Gruß
Pedro
Der an diesem Beitrag angefügte Anhang ist entweder nur im eingeloggten Zustand sichtbar oder die Berechtigung Deiner Benutzergruppe ist nicht ausreichend.
rh
Administrator
Avatar
Geschlecht:
Herkunft: Germany
Alter: 26
Homepage: e-lab.de
Beiträge: 5558
Dabei seit: 03 / 2002
Betreff:

Re: Brown Out

 · 
Gepostet: 01.02.2011 - 21:56 Uhr  ·  #4
Hallo Pedro,

die linke "read" Spalte ist identisch mit der rechten "write" Spalte. Also ist doch alles ok.

rolf
Gunter
Administrator
Avatar
Geschlecht:
Herkunft: Frankfurt Main / Germany
Beiträge: 1697
Dabei seit: 02 / 2003
Betreff:

Re: Brown Out

 · 
Gepostet: 01.02.2011 - 23:25 Uhr  ·  #5
Hi Pedro,

Rolf hat da wohl nicht nochmals den kompletten Thread gelesen
und Dein eigentliches Problem gar nicht gesehen.

Du musst bei existierenden Projekten

Define_Fuses
  Override_Fuses;
  LockBits0 ...

definieren!

Btw:
(nicht im Sinn von "RTFM" - als Hilfe zur Selbsthilfe gemeint)
das steht auch Alles in DocuCompiler.pdf:

4.6.8 DEFINE_FUSES
...
Alle Fuses sind low-active, d.h. wird ein Fuse Namen angegeben, z.B. "CKSEL1",
so wird dieses Bit auf NULL (low = aktiv) programmiert.
Nicht aufgezählte Fuses werden deshalb immer auf "1" (high = inaktiv) programmiert!
...
Bei der Neu-Erstellung eines Projekts werden diese Fuses automatisch in das ISPE-File
für den Programmer geschrieben.
Wenn das ISPE File schon existiert, wird es nicht mehr verändert.
Mit der Angabe "OverRide_Fuses" wird ein update in das ISPE File erzwungen.
OverRide_Fuses muss unmittelbar nach Define_Fuses stehen.


Gruß
Gunter

Nachtrag:
ein mDelay ganz am Anfang ist nie verkehrt!
Das soll aller angeschlossenen Peripherie genügend Zeit geben,
stabile Anfangsbedingungen zu erreichen bevor der 1. Zugriff erfolgt.
Pedro Veloceros
 
Avatar
 
Betreff:

Override => wrong device

 · 
Gepostet: 05.02.2011 - 22:23 Uhr  ·  #6
Hallo Gunther,

vielen Dank für Deinen wie immer fundierten und verständlichen Rat. Hab jetzt den override-Befehl eingefügt
Code

Define_Fuses
  Override_Fuses;
  LockBits0 = [];
  FuseBits0 = [];
  FuseBits1 = [BODLEVEL1]; // Binär 0 heißt: Bit gesetzt, hier also 0000 0101
  FuseBits2 = [];

Bedauerlicherweise erkennt jetzt der Programmer das Device nicht mehr (siehe Screenshot. Was habe ich falsch gemacht?

Gruß
Pedro
Der an diesem Beitrag angefügte Anhang ist entweder nur im eingeloggten Zustand sichtbar oder die Berechtigung Deiner Benutzergruppe ist nicht ausreichend.
Gunter
Administrator
Avatar
Geschlecht:
Herkunft: Frankfurt Main / Germany
Beiträge: 1697
Dabei seit: 02 / 2003
Betreff:

Re: Brown Out

 · 
Gepostet: 05.02.2011 - 23:19 Uhr  ·  #7
Hi Pedro,

Du hast nicht auf die CKSELx Fuses geachtet und diese jetzt auf "1111" programmiert!
FuseBits0 = [];
Der Tiny geht jetzt von einem Quartz/Resonator an XTAL1/XTAL2 aus und hat keinen Clock mehr.
Program Fuses programmiert natürlich immer ALLE Fuses!
Die müssen dann natürlich auch alle korrekt angegeben sein.

Wenn Du einen Quartz/Resonator oder einen externen Takt (Oszillator an CLKIN) anschliessen
kannst, ist der Tiny44 sicher wieder zu reaktivieren. Oder nimm gleich einen neuen.

Tipp:
zum "Basteln" besser das "Program Fuses" rausnehmen und nur für Änderungen aktivieren!
Und das erst nach doppelter Überprüfung.

Gruß
Gunter
Gewählte Zitate für Mehrfachzitierung:   0

Registrierte in diesem Topic

Aktuell kein registrierter in diesem Bereich

Die Statistik zeigt, wer in den letzten 5 Minuten online war. Erneuerung alle 90 Sekunden.
MySQL Queries: 8 · Cache Hits: 14   112   126 · Page-Gen-Time: 0.016247s · Speichernutzung: 2 MB · GZIP: ein · Viewport: SMXL-HiDPI