Brown-out detection auch bei ATtiny2313
18. Februar 2012 um 18:30 Uhr

Dieser Artikel ist eine kleine Aktualisierung zur Bauanleitung des 3-Leiter-Bus-Interfaces.

Zum Zeitpunkt der Entwicklung des 3-Leiter-Bus-Interfaces stand mir der AVR-Controller AT90S2313 zur Verfügung.

Als Reset-IC verwendete ich damals einen MCP100. Dieses “Reset-IC” hatte die Aufgabe, die Betriebsspannung zu überwachen und bei Unterschreiten der Mindestspannung den Controller auf Reset zu setzen, damit es zu keinen unkontrollierten Handlungen kommt.

Leider gibt es nur noch Reset-ICs in SMD-Ausführung. Ich habe kurzerhand diese SMD-ICs in die Bauteilliste eingetragen. Ich hatte allerdings nicht bedacht, dass der Push/Pull-Ausgang der neuen ICs es nicht erlaubt, die Reset-Leitung mittels eines Reset-Tasters auf low zu ziehen. Es fließt ein erheblicher Strom, welcher einen Vorwiderstand (4,7k) am Ausgang des Reset-ICs erforderlich macht. Damit wäre das Problem dann erledigt. ;-)

Siehe Bild

Anschaltung Reset-IC

 

Es gibt aber noch eine viel bessere Nachricht!

Wenn man einen ATtiny2313 anstatt des alten AT90S2313 verwendet, dann kann man auf das im Schaltungsentwurf gezeigte Reset-IC verzichten.

Beim Durchsehen der Datenblätter verschiedener AVR-Controller ist mir die erweiterte Reset-Logik aufgefallen. Auch der ATtiny2313 verfügt im Gegensatz zum AT90S2313 über diese erweiterte Reset-Logik. Die aktuellen Controller können damit die Betriebsspannung selbst überwachen und bei Unterspannung selbst Reset setzen. Um diese Funktion zu aktivieren muss man nur die Fuse BODLEVEL auf das gewünschte Trigger-Level setzen.

Der ATtiny2313 stellt drei Trigger-Level zur Verfügung:

Brown-out detection level at VCC=4.3V (BODLEVEL=100)
Brown-out detection level at VCC=2.7V (BODLEVEL=101)
Brown-out detection level at VCC=1.8V (BODLEVEL=110)

Für das 3-Leiter-Bus Interface ist BODLEVEL=4.3V meine Empfehlung, und das externe Reset-IC ist überflüssig. :-)

PS:
Ich verwende zur Programmierung und zum Setzen der Fuse-Bits der AVR-Controller das AVR-Evaluations-Board STK500 in Verbindung mit dem kostenlosen AVR-Studio4.

PPS:
War dieser Artikel hilfreich?
Benutzen Sie bitte die Kommentar-Funktion.


Incoming search terms:

  • attiny2313
  • at90s2313 projekte
  • simulate attiny2313
  • schaltungen mit attiny2313
  • mail dtection com loc:DE
  • bodlevel attiny
  • avr reset beschaltung mit brown-out detection
  • attiny85 brownout
  • attiny projekte
  • attiny brown-out

Tags: , , , , , , ,
Filed under: 3-Leiter-Bus,ATtiny2313,AVR von Uwe
Comments (2)

 


Die 3 wichtigsten Argumente für AVR
28. Januar 2011 um 21:21 Uhr

Heute erzähle ich Ihnen meine Geschichte, wie ich zu den AVR-Controllern gefunden habe.

Ich als Funkamateur und Radiobastler hatte eigentlich nichts mit Mikroprozessor und Co. am Hut. Will man jedoch mit der technischen Entwicklung Schritthalten, kommt man einfach nicht um die Verwendung eines Mikrocontrollers herum, um die Bedienung und Steuerung des selbstgebauten Gerätes zu realisieren. Auch, wenn es nur ein Mini-Projekt ist.

Klar, es gibt eine Menge verschiedenster Controller-Typen und Konzepte.
Wofür sollte ich mich also entscheiden?

Meine erste Begegnung mit Mikroprozessoren hatte ich in den 80ern, mit dem allseits bekannten Z80. Ok, der Z80 (damals z.B.U880) ist ein reiner Mikroprozessor ohne interne Peripherie. Also, man musste die Peripheriebausteine wie z.b. RAM, EPROM, SIO, PIO und CTC extern anschließen.

Man brauchte aber wenigstens einen (EP)ROM als Programmspeicher und irgend einen IO-Baustein, damit man überhaupt etwas sinnvolles damit anstellen konnte. Letztendlich hatte man immer ein Board, auf dem der Mikroprozessor und seine Peripheriebausteinen Platz finden mussten. Also, keine Rede von minimaler Hardware.

Allerdings hatte der Mikroprozessor einen recht umfangreicher Registersatz (Register A, F, B, C, D, E, H, L, Index-Register IX und IY) incl. einem Tauschregistersatz für schnelle Interrupt-Bearbeitung.

Der umfangreiche CISC-Befehlssatz von ca. 150 Befehlen war auch nicht zu verachten.

Besonders bemerkenswert fand ich auch die SIO, die unter anderem eine Hartwareunterstützung des HDLC-Protokolls und CRC-Erzeugung und Prüfung bietet, und damit dem Prozessor einiges an Arbeit abnimmt.

Zugegeben, das ist doch alles Schnee von gestern. Oder?

Später tauchten immer mehr Geräte auf, die mit einem Motorola-Controller MC68HC11 oder MC68HC05 ausgerüstet waren. Also habe ich die Programmierung des MC68HC11 erlernt, und einige kleinere Projekte realisiert.

Der MC68HC11 verfügte intern über 256Byte RAM, 512Byte EEPROM und einen BOOT-ROM. Zur Programmabarbeitung standen zwei 8-Bit-Arbeitsregister A und B, und zwei Index-Register X und Y zur Verfügung. Weiterhin verfügte der Controller über 5 IO-Ports, Port A bis E.

  • Der Port A steht hauptsächlich dem internen Timer-System zur Verfügung.
  • Der Port B stellt 8 Ausgänge bereit.
  • Der Port C stellt 8 Aus- oder Eingänge je nach Konfiguration bereit.
  • Über Port D ist das SPI (Serial Peripheral Interface) und SCI (Serial Comm. Interface) verfügbar.
  • Port E stellt 8 A/D-Wandler-Eingänge bereit.

Der interne EEPROM (512 Byte) kann als Programmspeicher verwendet werden. Für kleinere Projekte ausreichend. Will man aber ein ganzes Gerät steuern, muss man auf externen Programmspeicher (EPROM) zurückgreifen. Dafür muss man Port B und C für den externen Daten- und Adressbus opfern. Für mich als Funkamateur und Radiobastler kam ein weiteres Problem hinzu. Nicht nur, dass man zwei Ports für den externen Daten- und Adressbus opfern musste, es strahlte auch der externe Bus ein breites störendes Rauschen bis in den UKW-Bereich hinein ab. Eine etwas unbefriedigende Situation, will man z.B. einen „Funkapparat“ damit steuern.

Auch nicht das Richtige! :-(

Auf der weiteren Suche nach einem modernen Controller bin ich dann auf die 8Bit-RISC-Controller-Familien gestoßen. Es war nicht einfach zu entscheiden, welche Controller-Familie es nun sein sollte.

Ich habe mich nach einigen für und wider für die AVR-RISC-Controller-Familie entschieden.

Hier nun die 3 wichtigsten Argumente, warum ich mich für die AVR-8Bit-Controller entschieden habe.

  • Die Befehlsausführungszeit von einem Oszillator-Takt-Impuls für einen Befehl, das bedeutet bei 10MHz-Takt, die Ausführung von 10 Millionen Befehle pro Sekunde !! (10 MIPS) Andere Controller benötigen mindestens 4 Takte für die Ausführung eines Befehls.
  • Der Befehlssatz von über 100 Befehlen, der für RISC-Controller (Reduzierter Befehlssatz) doch sehr umfangreich ausfällt. Ein Umstand der mir sehr entgegen kam, als alter CISC-Programmierer. ;-)
  • Die 32 fast gleichberechtigten Arbeitsregister, die direkt mit dem Rechenwerk (ALU) verbunden sind. Dadurch wurde das Nadelöhr des traditionellen Akkumulator-Register deutlich entschärft. Die Register r26 bis r31 kann man außerdem als Index-Register-Paare X, Y und Z verwenden. (optimal für Hochsprachen wie C usw..)

Am Ende hatte ich mir eine Menge Gründe zurechtgelegt, die meine längst getroffene Entscheidung für die 8Bit-AVR-RISC-Controller-Familie unterstützten sollen.

Also habe ich mir das AVR-Evaluations-Board STK500 gekauft.
Entweder richtig oder gar nicht, hab’ ich mir gedacht.
Ich habe es nicht bereut, das STK500 benutze ich heute noch.

Ich glaube, es muss jeder für sich entscheiden ob nun PIC, AVR oder was auch immer. Jeder Controller-Typ hat seine Vor- und Nachteile, und kann z.b. eine bestimmte Aufgabe besser lösen als andere Controller und umgekehrt.

Meine Entscheidung war ganz klar …8Bit-AVR!
Und der ATtiny2313 ist für meine gelegentlichen Miniprojekte die erste Wahl.

PS:
War diese kleine Geschichte hilfreich, oder eher nicht?
Benutzen Sie bitte die Kommentar-Funktion.


Incoming search terms:

  • avr synthesizer
  • avr pll
  • pll mit atmega
  • atmega pll
  • hdlc avr
  • 8 bit synthesizer avr
  • pll with atmega
  • pll atmega1284
  • pic avr besser für c geeignet
  • phase locked loop atmega

Tags: , , , , ,
Filed under: Allgemein,ATtiny2313,AVR von Uwe
Comments (11)

 


PLL 3-Leiter-Bus Startseite Download
Navigation