Mein Treppenhausautomat

Wie hoch könnte die Stromaufnahme des 2313 sein? es werden dabei 3 x LED mit jeweils ca. 2 mA angsteuert und die Optokoppler

Kommt auf die Taktfrequenz und Betriebsspannung an. Laut Datenblatt bei 8MHz und 5V bis zu 6mA wenn aktiv, im Idle State ungefähr die Hälfte. Dazu kommt noch der Strom der entnommen wird (die LEDs).
Gibt stromsparendere Exemplare, aber ich glaub darauf kommts hier nicht an :)
 
Hallo Tommy
hatte überlegt einen anderen Trafo zu nehmen der kleiner ist. Leider macht das ca.2 bis 3 mm aus. Der jetzige hat 116mA und er andere 83 mA. Mal sehen ob es sich lohnt
achim
 
Es klang so, als wenn Du den 2313 gern als universellen Tiny für alles einsetzt, weil man sich dann eben nur mit dem einen auskennen muß...
DA würde ich dann aber eher auf einen mit ADC (möglichst differentiell und bipolar) und UART und SPI und TWI setzen. Egal.
Zum stromsparen hilft (wie Thomas bereits angedeutet hat) eine Reduktion der Betriebsspannung (was nebenbei vielleicht auch nochmal den Trafo verkleinert?) und der Taktfrequenz (bei manchen AVR kann man zB den Watchdog Oszillator als Systemtakt nutzen (@Thomas: und beim Tiny441 sogar zur Laufzeit variabel die ClockSources umschalten)).
Aber damit reduzierst Du eben den Strom den der Controller selbst verbraucht vom mA-Bereich in den µA (nA) Bereich (Oft wird die A/PA-Generation auch als picoPower-Variante bezeichnet, genaueres muß man den Datenblättern entnehmen). Dem gegenüber stehen aber immer Verbraucher im mehrstelligen mA-Bereich, um die Du Dich eher kümmern solltest.
Was sich bei dem Analog-Teil sparen läßt, kann ich nicht sagen, zum AVR:
  • über das Widerstandsnetzwerk fließt zB immer entsprechend der Codierschalter Strom. Wie oft müssen/sollen die den ausgewertet werden? Man könnte zB festlegen, daß die nur einmal nach einem Reset ausgewertet werden sollen. In der Software könnte man dann nacheinander(!) immer für einen Pin den internen Pullup aktivieren, den Pin auslesen, und den Pin danach auf Gnd legen (fester Pegel, kein Strom). Dann fließt während des Auslesens für jeden der Pins eventuell kurzzeitig Strom über den internen Pullup (10..50K oder so), und danach nicht mehr.
  • Bei den Anzeige LEDs könnte einerseits die Leuchtdauer begrenzt werden, andererseits könnte man auch sicherstellen, daß maximal eine LED gleichzeitig leuchten darf (wenn das nicht bereits so ist).
Ansonsten gilt es im Controller alle nicht benötigte Hardware abzuschalten, und wo möglich entsprechende Sleepmodes zu nutzen (war das nicht der Tiny2313 mit den Bugs im PRR (also in der Definitionsdatei), Thomas? Auf alle Fälle gab's hier die Bugs mit den PCINTs)

Zur 10ms-Zeitbasis: Ich hatte bei meinem Phasenanschnittsdimmer (also Nulldurchgangsdetektion und verzögertem Zünden der TRIACs) zum Tasterentprellen einfach die Nulldurchgangsinterrupts als Zeitbasis mitverwendet. Etwa 10ms ;).

P.S.: Zu stromsparenden Indikator-LEDs hat Dino irgendwann mal gepostet, daß es stromsparender wäre Ultrahelle LEDs über einen 1K-Widerstand zu verwenden (funzeln dann bei <1mA vor sich hin) als konventionelle lowPower LEDs mit 3-5mA (die da auch nicht viel heller sind)
Alternativ kannste natürlich auch über ein eInk-Display nachdenken:p
 
Hi,

P.S.: Zu stromsparenden Indikator-LEDs hat Dino irgendwann mal gepostet, daß es stromsparender wäre Ultrahelle LEDs über einen 1K-Widerstand zu verwenden (funzeln dann bei <1mA vor sich hin) als konventionelle lowPower LEDs mit 3-5mA (die da auch nicht viel heller sind)

bei 5V Vcc einen 6,8k Vorwiderstand für die LED. Reicht bei den ultrahellen allemal aus. ;)

Wenn man bei den DIP-Schaltern die internen PullUps verwendet, dann spart das auf jeden Fall gegenüber den externen ne Menge Strom. Die internen liegen irgendwo bei 40-50k wenn ich das recht in Erinnerung habe.

Gruß
Dino
 
@LotadaC:
Nicht ganz. Beim Tiny13 wurde das PRR in der Definition vergessen, beim 2313 war aber auch irgendein Bug in den Defs. Aber ich hab den nie verwendet. Der Bug war aber afaik nur im Simulator 2 und ist an Atmel weiter gereicht. Mit etwas Glück ist der mittlerweile behoben *räusper*
 
Hi,

insbesondere, wenn man die nach erfolgter Auswertung abschaltet, wie gesagt...

so aus meinem Gedächtnis soll man die laut Datenblatt zum Stromsparen sogar an lassen da dadurch ein wildes Schwingen der Eingänge durch irgendwelche Einstreuungen verhindert wird. Wenn also der DIP-Schalter bei einem Pin offen ist, sollte man zum Stromsparen einen definierten Pegel anlegen. Jede Pegeländerung bei CMOS-Bausteinen kostet wegen dem Umladen der Gates Strom.

Gruß
Dino
 
@Dino: genau genommen hatte ich oben deswegen geschrieben...
...In der Software könnte man dann nacheinander(!) immer für einen Pin den internen Pullup aktivieren, den Pin auslesen, und den Pin danach auf Gnd legen (fester Pegel, kein Strom). Dann fließt während des Auslesens für jeden der Pins eventuell kurzzeitig Strom über den internen Pullup (10..50K oder so), und danach nicht mehr...
@Thomas: Beim Tiny2313 sind alle PortB-Beine PCINTs, und werden im PCMSKmaskiert, besitzen im GIMSK ein gemeinsames Interrupt Enable Bit und im EIFR ein gemeinsames Interrupt-Flag. Beim Tiny2313A und dem Tiny4313 (der eigentlich ein 2313A mit doppelt Speicher ist) sind alle I/Os PCINTs, er besitzt folglich 3 PCMSKs und 3 Bits für die PCINTs in GIMSK und GIFR (statt EIFR)

Diese Bits und Register existieren in den Definitionsdateien (da C&P aus dem Tiny2313) und im Simulator AFAIR nicht, da PCMSK0 auf derselben Adresse liegt wie PCMSK beim 2313, kann man die so maskieren, und im Code EIFR statt GIFR schreiben. ein weiterer Fehler war, daß die Bits in GIFR/GIMSK nicht in der 2|1|0-Reihenfolge liegen, da stimmen die Konstanten nicht. Das betraf nicht nur den Simulator.
In der Realität konnte man natürlich entsprechende Konstanten in die Register schreiben/selbst definieren bzw die Definitonsdateien korrigieren/ergänzen. Das die dann immer noch im Simulator fehlten/verdreht waren is 'ne andere Sache. Ob das inzwischen korrigiert wurde, weiß ich nicht (könnte man ja mal ausprobieren, hab hier noch 3 rumzuliegen)
AFAIR war der Bug in unterschiedlichen Entwicklungsumgebungen und Versionen unterschiedlich stark ausgeprägt...
 
Mag sein dass es bei dem Chip noch mehr Bugs gibt. Den den ich gemeldet hatte betraf allerdings ausschließlich den Simulator 2.

TommyB schrieb:
Hello,

an user in a forum where I am, too, has found a bug inside the AVR Studio since (at least) version 4.18. I can confirm that with version 4.19.
This bug applies only to the AVR simulator 2 (the first simulator version does NOT have that bug).

Something went wrong with the ATtiny2313.

Steps to reproduce:

Use the following test code:
.INCLUDE <tn2313def.inc>

ldi r16, 1<<PCIE
out GIMSK, r16
in r17, GIMSK

break

Step through it in the simulator 2.
R16 will get the value 0x20 (correct)
GIMSK will get the value 0x08 (as the simulator says. Wrong. I/O view is corrupted also. Of course it should have 0x20)
R17 will get the value 0x20 back from GIMSK.

I compared the include files of both simulators, they seems to be equal (at least for the used registers and definitions).
I don’t know if this bug applies to other chips as well.
Atmel schrieb:
Hello Thomas Baumann,
Thank you for contacting Atmel Technical support.
We were also able to reproduce the issue at our end for ATtiny2313 device, Unfortunately that is a bug and it is reported to the internal team, hopefully it will be resolved in the future version of Atmel Studio.
Thank you for informing us about the bug.
Das war im Dezember 2013. Finde den Thread hier nicht mehr.

p.s.: Wir sind nu n bissl in's off-topic gerutscht ;)


Edit: gefunden.
 
Nach längerer Zeit habe ich die Platine endlich fertig gemacht. Im Grund besteht sie aus zwei teilen. Einmal die Grundplatine mit der Netzspannung drauf und die Steuerplatine mir Einstellung, Anzeige, Prozessor, Netzteil, Optokoppler usw. Der Prozessor läuft bereits und kann über ISP programmiert werden. Verwende einen ATi 2313 mit 16MHz. Einiges kann noch verbesert werden. Der Stecker auf der Platine dient zum testen der Software als Tasterersatz. Die einzelne LED auf der Platine benutze ich als Kontrolle. Den Taster habe ich entprellt damit nichts verloren geht. P6212648_(800_x_600).jpg
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)