Forum

Vorschlag - ATtiny1634, bzw. ATmega328P; bzw. PIC (Bauelemente)

verfasst von bastelix, 19.05.2016, 01:38 Uhr

» Mal fürs Erste µC Wahl, nächstes /Versorgungen umschalten, Batt-Management/
» folgt demnächst:
»
» Hauptgedanke hier - Strom sparen, u.A. durch Umschalten der Taktfrequenzen.
» / "Picopower" lt. Atmel; XLP bei PIC.
»
» Vorschlagend mal für den Controller wäre der ATtiny1634 von Atmel.
» http://www.atmel.com/Images/Atmel-8303-8-bit-AVR-Microcontroller-tinyAVR-ATtiny1634_Datasheet.pdf
Der 1634 hat glaub ich nen Pferdefuß - da steht nur was von SOIC und QFN/MLF im Datenblatt, das ist doch beides SMD... Wobei mittlerweile eh schon Wurst. Hab heute versucht einen der ausgesuchten Spannungswandler aufzutreiben. Entweder nur die 3-Pin-Variante (ohne abschalten) oder nur 5V oder eben SMD (bei RS, Farnell, eBay, ...). Hab eben noch den Tipp bekommen bei aliexpress zu schaun, da ist die Auswahl wesentlich größer. Muss ich mir morgen nochmal genauer anschauen...

So ein SOIC mit 8 Beinen könnte ich aktuell noch händisch löten, hab das heute mal an nem alten Mainboard ausprobiert (zwei Käfer verpflanzt, ob die das auslöten überlebt haben weiß ich nicht aber mechanisch iss alles gut gegangen ) Werde dann doch eher früher als später in ne neue Lötstation investieren, aber das steht in nem anderen Thread

Zurück zum Thema.

Eigentlich will ich den ESP möglichst viel direkt machen lassen, der hat ja ausreichend Ressourcen. Ich werde auch kein ESP-01-Modul einsetzen sondern einen ESP-12 [1][2]. Da sind mehr Pins nach außen geführt, auch der Pin den der ESP verwendet um sich selber aus dem Tiefschlaf zu wecken. Den zusätzlichen µC würde ich nur zum Schalten der Spannungswandler verwenden und ggf. den ESP zu wecken.

Ich würde den ESP nur ungern als reines WiFi-Modem verwenden. Damit habe ich vor ca. einem Jahr experimentiert (zusammen mit einem Arduino Due). Das hat zwar funktioniert, aber die Reichweite war wesentlich geringer als bei meinen aktuellen Versuchen mit einem direkt programmierten ESP [3].

Soweit ich das verstehe muss man den Shutdown-Pin der LDOs auf High setzen um diese abzuschalten (Zumindest verstehe ich die Datenblätter der ausgesuchten LDOs so). Hier fehlts mir mal wieder an den Grundlagen. Wenn ich einen µC schlafen lege, was passiert dann mit den Pins? Bleiben die auf dem zuvor festgelegtem Pegel oder ist deren Level undefiniert während der µC schläft? Wenn der Pegel undefiniert ist, dann müsste da was mit Pull-Up/Down-Widerständen gemacht werden, oder?

Für meine Anwendungsfälle wäre es auch möglich einen µC als Arbeitstier zu verwenden und den ESP dann die Daten abholen und übertragen zu lassen (ähnlich deiner Überlegung, nur halt aktiver ESP statt AT-Befehle). Mit deiner/eurer Hilfe trau ich mir schon zu, dass ich das vorletzte µA rausquetsche... Aber das würde (zumindest aus Programmierer-Sicht) die Komplexität des Gesamtsystems noch weiter erhöhen. Eigentlich soll die Platine ja auch von Leuten mit weniger Ahnung von E-Tech (da ist bei mir nicht mehr so viel Luft nach unten ) und Programmierung (da geht schon wesentlich mehr ) verwendet werden können. Wenn der Aufbau dann ein paar mA mehr verbrät als idealerweise möglich, dann kann/muss ich damit leben. Irgendwo muss ich Kompromisse eingehen.

Was du da über die Taktfrequenz vom zweiten µC geschrieben hast finde ich sehr interessant. So grob kann ich dir auch folgen, aber um das wirklich zu verstehen brauch ich noch ein paar Tage (ein paar Tage mehr als ich Urlaub hab )

Von der Software- und Netzwerkseite her: Der ESP sendet aktiv, es soll also kein (Web)-Server auf dem ESP laufen (wie das gerne bei den ESP-Beispielen im WWW gemacht wird) sondern er verbindet sich mit einem Server und überträgt an diesen seine Daten. Was mit den Daten dann passiert ist dem ESP egal. Längeres vorhalten der Daten auf dem ESP ist aktuell nicht geplant. Das könnte man zwar realisieren, aber dann würde die Komplexität auf der Softwareseite steigen (das Synchronisieren wird damit Komplexer)

Für erste Tests hatte ich nen simplen TCP-Server gecoded der die empfangenen Daten auf die Konsole ausgibt.
Mittlerweile sieht das ganze so aus: Der ESP verbindet sich via WLAN mit einem Message-Broker (MQTT-Protokoll, aktuell Apache ActiveMQ 5.13.3 [4]) und schickt die verschiedenen Messwerte (aktuell Temperatur, Luftfeuchte, Vcc) in die jeweiligen Queues (je eine Queue für Temperautr, Luftfeuchte und Vcc). Der Message-Broker verteilt dann die Nachrichten/Messwerte an die jeweiligen Subscriber (aktuell nur ein in Ruby geschriebener Daemon der die Messwerte dann in einer RethinkDB [5] speichert und zusätzlich ins Debug-Log schreibt). Später kommt dann noch ne Webanwendung dazu, die dann die Messwerte aufbereitet und ausgibt (vermutlich auch wieder Ruby, das Sinatra-Framework bietet sich da an). An den Message-Broker könnten sich auch weitere Subscriber anmelden, z.B. Aktoren, aber soweit bin ich noch lange nicht.

» Ein anderes zB - mit dem Tiny44 ein ESP-01 Wifi-Relais:
»
» Achtung!!! Diese Schaltung dient nur als Referenz, da ich nicht überprüft
» habe, ob sich richtig ist; im ersten Blick passt's soweit. - dort näher
» gucken bitte.
Was mir bei der Schaltung aufgefallen ist: Ich würde den Pin 4 (CHPD) nicht (mehr) ohne Strombegrenzung auf Vcc klemmen. Ok, hab ich früher auch so gemacht und es ist nix kaputt gegangen, aber drauf verlassen würde ich mich nicht da ich ja jetzt weiß, dass der Pin max 12mA verkraftet und sich mit 6mA wohler fühlt. Der ATTiny müsste als Output 20/40mA verkraften (so aus dem Hinterkopf) aber ob/wie da der Strom begrenzt wird weiß ich nicht. Darum würde ich auf Nummer sicher gehen und einen Widerstand verwenden. Oder nochmal nachlesen, das war jetzt so aus dem Bauch raus.

[1] http://www.esp8266.com/wiki/doku.php?id=esp8266-module-family
[2]
[3] https://github.com/esp8266/Arduino
[4] http://activemq.apache.org/
[5] https://www.rethinkdb.com/