Um Strom zu sparen und die Elektronik möglichst einfach zu halten, bin ich auf der Suche nach einer Lösung, einen Verbraucher zeitgesteuert zu schalten ohne aber einen Mikrocontroller zu verwenden. Beim Verbraucher handelt es sich um Embedded Hardware mit GPIOs, über die ein Wert für die Zeit-Schaltung ausgegeben werden soll. Um es laienhaft auszudrücken: Gibt es ein billiges Bauteil, das sich wie eine "Eieruhr" verhält und mir den Verbraucher an bzw. aus macht? Vielen Dank!
Simon Tretter schrieb: > Um Strom zu sparen und die Elektronik möglichst einfach zu halten, bin > ich auf der Suche nach einer Lösung, einen Verbraucher zeitgesteuert zu > schalten ohne aber einen Mikrocontroller zu verwenden. > > Beim Verbraucher handelt es sich um Embedded Hardware mit GPIOs, über > die ein Wert für die Zeit-Schaltung ausgegeben werden soll. > > Um es laienhaft auszudrücken: > Gibt es ein billiges Bauteil, das sich wie eine "Eieruhr" verhält und > mir den Verbraucher an bzw. aus macht? Gibt es. Nennt sich 555 und die Schaltung heißt 'Monoflop' Aber: Der springende Punkt ist: wie willst du die Zeit vorgeben? Solange das analog mit einem Poti sein soll, geht ein 555. Wenn du das Zeug digital irgendwo vorliegen hast, dann ist ein µC in Punkto Einfachheit und Aufwand nicht zu schlagen.
Mir würde konkret ein Kondensator einfallen. Dann müsstest du die Zeitkonstante auslegen, die du brauchst und eine entsprechende Schaltung.
Vielen Dank für deinen Kommentar! Ich möchte die Zeit digital über die GPIOs der Hardware vorgeben. Da die aber ausgeschaltet werden soll benötige ich eine Logik, die sich die Zeit "merkt" und wieder anschaltet.
Simon Tretter schrieb: > Um Strom zu sparen und die Elektronik möglichst einfach zu halten, bin > ich auf der Suche nach einer Lösung, einen Verbraucher zeitgesteuert zu > schalten ohne aber einen Mikrocontroller zu verwenden. So weit so gut, aber warum? Ein µC ist auch nichts anderes als ein Stück Silizium. Ob du nun die Werte über analoge Bauteile oder über Software festlegst macht außerhalb der Raumfahrt doch keinen Unterschied. Simon Tretter schrieb: > Ich möchte die Zeit digital über die > GPIOs der Hardware vorgeben. Da die aber ausgeschaltet werden soll > benötige ich eine Logik, die sich die Zeit "merkt" und wieder > anschaltet. Was die Schaltung wohl so komplex macht das ein µC einfacher ist (der hat internen Speicher der auch nach ausschalten den Wert behält). Wenn es darum geht das die Kenntnisse zum programmieren fehlen wird sich bei der einfachen Funktion vermutlich jemand finden lassen der das macht ohne das Budget groß zu belasten.
Danke für deinen Rat. Die Werte gebe ich ja schon über einen Controller vor, nur ist es eben der der ausgeschaltet werden soll um Strom zu sparen (es geht um jedes mW). Es geht also eher um ein Zeitrelais, das sich den per GPIO vorgegebenen Wert merkt, wenig Strom braucht und superkompakt und billig ist.
Simon Tretter schrieb: > Danke für deinen Rat. Die Werte gebe ich ja schon über einen Controller > vor, nur ist es eben der der ausgeschaltet werden soll um Strom zu > sparen (es geht um jedes mW) Macht ja nix. So ein AVR braucht im Sleep so wenig Strom, dass du das getrost vergessen kannst. Da kommst du mit diskreter Beschaltung sowieso kaum hin. Und nein. Wir reden da nicht über mW sondern über µA.
Simon Tretter schrieb: > Gibt es ein billiges Bauteil, das sich wie eine "Eieruhr" verhält und > > mir den Verbraucher an bzw. aus macht? Kannst du die Funktion nicht mit einen reset circuit realisieren? Der ist doch ohne of den meisten boards drauf. Den an einen weiteren ResC, ein MonoFlop oder einen einfachen RC-Schaltkreis.
Simon Tretter schrieb: > Es geht also eher um ein Zeitrelais, das > sich den per GPIO vorgegebenen Wert merkt, wenig Strom braucht und > superkompakt und billig ist. Das geht auch mit µCs im NanoWatt Bereich (sicher auch bei AVR obwohl ich eine andere Marke nutze). Da kommt kein analoges Zeitrelais hin da es sonst viel zu hochohmig (und damit Störanfällig) wird.
Vielleicht sind die Timer Blox von LT was für dich. Z.B. LTC6991. Die werden aber eigentlich über Widerstände eingestellt und ich fürchte mit nem DAC wird das schwierig wenn die Zeit genau sein soll. Abgesehen davon, die meisten Low-Power µCs im Sleep mit Timer am laufen brauchen auch <1mW, MSP430 1,8µA bei 3V.
Dr. Schäfer schrieb: > Timer am laufen > brauchen auch <1mW, MSP430 1,8µA bei 3V. Hier geht es bei 9nA los, wer bietet weniger ;-). http://www.microchip.com/pagehandler/en-us/technology/xlp/
Jens Martin schrieb: > Hier geht es bei 9nA los, wer bietet weniger ;-). > > http://www.microchip.com/pagehandler/en-us/technology/xlp/ Der gefällt mir auch, hab nur den MSP als populäres Beispiel genommen :-) Bei 3nA läuft da aber auch keine Clock mehr, also 550nA dürfens schon sein für den Watchdog.
Simon Tretter schrieb: > Danke für deinen Rat. Die Werte gebe ich ja schon über einen Controller > vor, nur ist es eben der der ausgeschaltet werden soll um Strom zu > sparen Ja und es gibt eine ganze Reihe von µCs die genau dafür gemacht wurden. Die schalten selbst ihre Peripherie bis auf den Timer ab und legen sich schlafen. Der Timer weckt sie zyklisch und sie schauen nach ob sie weider aktiv werden sollen. Dazu braucht man keinen 2. µC oder analoge Zeitschalter, die brauchen mehr Energie um den dicken Elko zu laden.
Dr. Schäfer schrieb: > Bei 3nA läuft da aber auch keine Clock mehr, also 550nA dürfens schon > sein für den Watchdog. Ja aber der BOR, woraus man sich was basteln kann wenn es dann unbedingt sein muss. Watchdog ist natürlich einfacher, wobei der das kleine Wunderwerk periodisch aufweckt und man die Leistungsaufnahme über ein paar Minuten betrachten sollte (ist auch leichter zu messen). Wenn ein Signal das ganze aufwecken soll/kann sind wir bei deep sleep und 9nA. Das toppt wohl keine wie auch immer geartete eigene Bastellösung.
Simon Tretter schrieb: > Gibt es ein billiges Bauteil, das sich wie eine "Eieruhr" verhält und > mir den Verbraucher an bzw. aus macht? eine mechanische Zeitschaltuhr gibts im Baumarkt für 3 EUR.
Wegstaben Verbuchsler schrieb: > Simon Tretter schrieb: >> Gibt es ein billiges Bauteil, das sich wie eine "Eieruhr" verhält und >> mir den Verbraucher an bzw. aus macht? > > eine mechanische Zeitschaltuhr gibts im Baumarkt für 3 EUR. Das ist aber kein Bauteil sondern ein Gerät.
Fazit: Implementiere es mit dem bereits vorhandenen Mikrocontroller, falls möglich. Ansonsten baue Dir so einen Timer mit einem zweiten (kleinen) Mikrocontroller.
Vielleicht sollte er uns mal sagen welchen µC er benutzt. Ich habe vor kurzem etwas ähnliches mit dem STM32L1xx gemacht einfach vor dem Stopmodus die RTC anschmeißen, die nach einer vorgegeben Zeit einen externen Interrupt auslöst.
Ich verwende keinen µC sondern einen WLAN Router mit OpenWRT. Der soll an Solar betrieben und zu variierenden Zeiten abgeschaltet werden. Das "Problem" ist, dass ich extra keinen "intelligenten" Laderegler mit µC verwende und es jetzt irgendwie Schmerzt, dass für diese Funktionalität ein µC doch erforderlich wird.
1. Es gibt µPs die "fast" keinen Strom verbrauchen und bipolare Relais. 2. Seit vielen Jahren kennen wir die gute alte Zeitschaltuhr. Als Fertiglösung. Die meisten µPs wissen was die Stunde geschlagen hat, weshalb mir dein Problem doppelt-gemoppelt vorkommt.
Vielen Dank für die vielen Anregungen: auf unserem Vereinstreffen wurde gestern intensiv diskutiert 8-) übrigens: Geek-P0rn vom feinsten mit den 9nA im deepsleep... Unser WLAN-Router (typisch 5 Volt/100 mA bzw. 3.3 Volt/150 mA) soll per Photovoltaik betrieben werden. Zu bestimmten Zeiten die das Geraet selber vorgibt soll es ausgeschaltet werden (z.b. zu Zeiten mit geringer zu erwartender Nutzung). Man könnte diese Daten per GPIO, seriell oder USB raus/reinpusten. Stellt sich natuerlich die Frage, wie kräftig ein µP sein müsste um ein primitiv-Protokoll zu implementieren (hoeren + reden). Was soll also ueber das Protokoll laufen: - Kommando: "schalte mich X Stunden aus" - Kommando: "sage mir die Spannung der Batterie" - Kommando: Softwarewatchdog auf µP "kitzeln" (sonst Strom aus+ein) Es braucht also eine Schaltung mit µP die folgendes kann: - I/O mit serieller Schnittstelle - geringe Stromaufnahme im sleep (scheint nicht das Problem zu sein) - messungen von 2 verschiedenen Spannungen (Batterie + PV-Modul 0...7 Volt) - ein/ausschalten unseres Verbrauchers (ohne Relais?) - ein/ausschalten Batterieladung Wie programmiert wird (C/ass) ist egal, das schaffen wir schon 8-)
@BB Die meisten der Atmel-Chips haben alles was Du forderst "eingebaut". A/D-Wandler, U(S)ART und Hundezwinger. Viele haben ein EEPROM und sind somit auch "Nachtragend" wenn jemand den Stöpsel zieht. Ein paar lassen sich mit 08/15-Uhrenquarzen antörnen und können auf minimalsten Stromverbrauch getrimmt werden. Zusammen mit bistabilen Relais kann dann unter Magerkost sogar geschaltet werden. Herz was willst du mehr?
Bei den ATtinys gibt es leider keinen, der sowohl UART als auch A/D-Wandler hat, aber wenn die serielle Kommunikation auch per I²C oder SPI (zur Not auch Soft-UART) sein darf, wäre ein ATtiny24/44/84 mit Uhrenquarz für die Aufgabe ideal.
Vielen Dank für die Anregungen. Die Vielfalt der AVR Familie hat uns....verwirrt. Wir werden uns erstmal "alles" bestellen um mit einem ATmega8L zu basteln und die Grenzen auszuloten. Die Schaltung inkl. Software wird OpenSource - wir werden berichten.
Deine Anwendung ist nicht besonders exotisch, das Problem haben andere schon gelöst. Es gibt extrem stromsparende Real-Time Clocks (RTCs), bei denen du eine Zeit hinterlegen kannst, zu der sie deinen Router wieder aufwecken sollen. Das kann auch gerne incl. Datum sein. Microchip macht sowas z.B.
Nur mal so als Hinweis: Es macht wenig Sinn, wenn man einen 9nA uC nutzt, wenn man diesen mit einem billig Netzteil betreibt, dass selbst 1W in Wärme umsetzt. Ist jetzt übertrieben, aber darauf läuft es doch hinaus: Ihr wollte einen Router an einer Solaranlage betreiben, der über einen möglichst energiesparenden Chip geschaltet werden soll, was wenig Sinn macht, wenn der Chip dann an einem Netzteil hängt welches wegen konstanter Unterforderung (wenn der Router abgeschaltet ist) in einem misrablen Wirkungsgrad läuft. Es ist viel einfacher einen weit verbreiteten Chip zu nehmen. Zur Lösung selbst: Wenn der Router einen linux kernel verwendet und dieser als open-source zur Verfügung steht, dann bindet den uC via I2C als power-management chip mit an und steuert ihn über die entsprechenden Funktionen. Chhips mit ähnlichen Funktionen gibt es schon im Quelltext, was fehlt (Zeitsteuerung) muss man dazu programmieren. Warum I2C? I2C kann beiderseitig vom Timing her verzögert werden. Man ist also weder darauf angewiesen schnell genug zu sein, dass man als Slave alle Clocks vom Master mit bekommt, noch muss man auf exakte Timings achten. Also kann man den ATxxx mit lediglich einem 32kHz Uhrenquarz takten und ihn in den DeepSleep schicken aus dem er nur aufwachen muss, um die Uhr weiter zu stellen. Dazu muss er nicht einmal Beschleunigen, also auf xMHz umschalten. Möchte man zur Laufzeit, also wenn das System aktiv ist, mehr machen, kann man dann auch auf die interne Clock des AVRs schalten, deren Ungenauigkeit und Temperaturabhängigkeit für I2C irrelevant ist. Aber ich habe da noch eine ganz andere Idee... Es gab doch von NXP mal diese I2C Uhrenbausteine. Diese hatten eine Uhr, ein oder mehrere Alarmzeit Speicher, Interrupt Ausgang und I2C. Sie funktionierten mit einem GoldCap als Überbrückungsversorgung Wochenlang... Warum nicht einfach im Router eine Funktion einbauen, dass der den nächsten Einschaltzeitpunkt in diesen Chip programmiert und sich dann selbst den Saft klaut. Der Uhrenchip schaltet mit seinem Interrupt Pin dann den Router wieder ein. Parallel zum Interrupt kann man noch einen Taster schalten, der dann manuell einschaltet. Ich kann heute Abend gerne mal nachsehen, ob ich den PCFxxxx noch finde, mit dem ich mal ähnliches gemacht habe, vor vielen Jahren. Gruß, Ulrich
Du kannst auch einen einfachen externen Zähler IC verwenden, der einfach den µC jede Minute neu startet, und ggf. nur für 10 Sekunden Strom drauf gibt. Wenn Du die Spezifikation etwas ausdehnst laufen die Dinger mit erstaunlich wenig Strom. Ich glaube ich hab das mal mit einem 4060 gesehen. Aber ich mag mal behaupten, dass in Deiner Anwendung das µA, dass der µC im Sleep-Modus zieht relativ egal ist. Wenn Du das Interface zum Router per GPIO schaffst, kannst Du sogar auf den normalen Quarz verzichten, und den µC entweder direkt mit dem Uhrenquartz betreiben, oder ihn nur über den Uhrenquartz aufwecken lassen, um ihn dann mit dem internen RC-Oszillator zu betreiben.
R. Max schrieb: > Bei den ATtinys gibt es leider keinen, der sowohl UART als auch > A/D-Wandler hat Na aber sischer dat: http://www.atmel.com/devices/ATtiny1634.aspx
Bastian Bittorf schrieb: > Wir werden uns erstmal "alles" bestellen um mit einem > ATmega8L zu basteln und die Grenzen auszuloten. Also in einen Tiny85 (8pinner) paßt die USB-Lib und den gibt's auch schön stromsparend :-) So wegen zu wenig Platz und so :-P
Ulrich P. schrieb: > Es gab doch von NXP mal diese I2C Uhrenbausteine. Jaaa, die gibt es auch von Dallas/Maxim auch. Brauchen um 500nA. Laufen an 1Farad etwa einen Monat.
Knut Ballhause schrieb: > R. Max schrieb: >> Bei den ATtinys gibt es leider keinen, der sowohl UART als auch >> A/D-Wandler hat > > Na aber sischer dat: > > http://www.atmel.com/devices/ATtiny1634.aspx Ah - schön zu sehen, daß sich in dem Bereich was tut, und dann sogar gleich mit zwei UARTs, ordentlich Speicher und (laut Digi-Key) zu einem vernünftigen Preis. Als einziger Wermutstropfen sind mir spontan die 12MHz ins Auge gesprungen. Ich dachte, Atmel legt die neuen Controller alle auf bis zu 20MHz aus. kopfkratzer schrieb: > Also in einen Tiny85 (8pinner) paßt die USB-Lib und den gibt's auch > schön stromsparend :-) USB war aber nicht gefordert, außerdem hat der Tiny85 mindestens einen Pin zu wenig für die in Beitrag "Re: Zeitgesteuertes Schalten eines Verbrauchers ohne Mikrocontroller" gelisteten Aufgaben.
R. Max schrieb: > Als einziger Wermutstropfen sind mir spontan die 12MHz ins Auge > gesprungen. Ich dachte, Atmel legt die neuen Controller alle auf bis zu > 20MHz aus. Was mit 12Mhz nicht läuft, läuft mit 20 auch nicht ;-). Bin mir aber sicher, dass man das Teil auch mit 20Mhz betreiben kann, wenn man will.
Knut Ballhause schrieb: > R. Max schrieb: >> Als einziger Wermutstropfen sind mir spontan die 12MHz ins Auge >> gesprungen. Ich dachte, Atmel legt die neuen Controller alle auf bis zu >> 20MHz aus. > > Was mit 12Mhz nicht läuft, läuft mit 20 auch nicht ;-). Klar, ich sage ja nicht, daß er deswegen unbrauchbar ist, meine AVRs laufen eh meistens mit dem internen Oszillator, aber etwas überrascht war ich schon, ein neues Modell zu sehen, bei dem keine 20MHz dran stehen. > Bin mir aber sicher, dass man das Teil auch mit 20Mhz betreiben > kann, wenn man will. Mag sein, andererseits wird Atmel nicht ohne Grund 12MHz ins Datenblatt geschrieben haben und nicht 20.
Jaja - locker bleiben ;-)
Simon Tretter schrieb: > Ich verwende keinen µC sondern einen WLAN Router mit OpenWRT. Der soll > an Solar betrieben und zu variierenden Zeiten abgeschaltet werden. Das > "Problem" ist, dass ich extra keinen "intelligenten" Laderegler mit µC > verwende und es jetzt irgendwie Schmerzt, dass für diese Funktionalität > ein µC doch erforderlich wird. Ich finde es viel schmerzlicher, dass Du ausgerechnet die Komponente verweigerst, die Dein Problem am einfachsten lösen könnte... Aber um die anderen Kollegen wieder auf den rechten Weg zu bringen mit ihren Vorschlägen, falls es doch ein uC werden soll / darf: 12MHz sind viel zu viel für die gestellte Aufgabe. 32kHz reichen für ganz wenig Verbrauch und Gangenauigkeit der Uhr. Ist die Weckzeit erreicht, schaltet man auf die internen 1MHz. Die reichen dann im Fall einer I2C Kommunikation auch vollends um Stunde/ Minute für das nächste automatische Einschalten zu programmieren und dem Host gegenüber zu quittieren. Warum jetzt für die obige Aufgabe noch Analog-Kanäle, USB und Serielle hinzudiskutiert werden, ist mir nicht klar. USB benötigt 16MHz und mehr, nur um die gleichen 4 Byte (Stunde und Minute für Wakeup und aktuelle Uhrzeit) zu übertragen. Zudem braucht die Software-Emulation neben der höheren Taktung auch noch länger wegen der ganze USB Verhandlung - vermutlich 100x so viel Energie wie mit I2C und sie blockiert im Router auch noch den USB Port. Ein Atmega32U4 braucht via PLL sogar 40MHz oder 48MHz... Dafür hat man das USB in Hardware. USART hatten wir doch schon ausgeschlossen, weil die interne Clock vom AVR zu ungenau ist um eine stabile Datenrate zu realisieren. Sie ist zudem auch sehr stark temperaturabhängig. Natürlich könnte man einen ADC Kanal dazu nutzen irgendwo aus der Solaranlage eine Spannung abzufragen, um den Router trotz eingestellter Zeit nicht einzuschalten. Z.B. um die Akkus vor Tiefentladung zu bewahren, wenn die Panels zu lange mit einer zu dicken Schneeschicht bedeckt waren. Aber das war nicht die gestellte Aufgabe. Und das kann eine analoge Schaltung via Schmitt Trigger auch auf einen digitalen Eingang signalisieren. Was haben wir denn: Einen vollwertigen Router mit einem Kernel, der mit einer Linux-Zeit umgehen kann. Er kann auch einfach errechnen, wie viele Sekunden von jetzt bis zum nächsten Einschalten vergehen sollen. Dann kann er diese Zeit in den uC senden und sich selbst herunter fahren und ein FlipFlop resetten, dass seine eigene Versorgung frei schaltet. Was fehlt: Ein uC, der via I2C die obigen Sekunden entgegen nimmt, mit 32768Hz Uhrenquarz diese Sekunden über einen Timer abzählt und dann bei 0 stoppt, einen Pin wechselt, dass der das FlipFlop wieder umschaltet und den Router startet. Addon 1) Ein Input für einen Taster der den uC veranlasst manuell den Router zu starten Addon 2) Ein Input, der analog oder digital erfasst, ob eingeschaltet werden darf. Das geht locker in einen klitze kleinen ATtiny. Am einfachsten ist es immer noch, die Lösung mit einem der kleinen NXP/MAXIM Uhrenchips zu lösen. Zumal für einige dieser Kameraden bereits fertige Treiber im Linux Kernel existieren. Man müsste also nur eine kleine Trickschaltung am DC/DC Wandler des Routers vornehmen, damit man diesen abschalten kann. Viele DC/DC Chips haben aber einen solchen Pin. Vorteil der Uhren-IC Lösung ist, dass man nix oder ein wenig am Kernel programmieren muss um das zu realisieren. Nachteil ist, dass man eine Blockierung gegen Einschaltung bei Unterversorgung oder einen Taster mit etwas mehr Hühnerfutter umsetzen muss, um zu entprellen oder mit Comparatoren eine Schaltschwelle zu finden. Aber der Router Prozessor kann ja einen GPIO abfragen und sich gleich wieder abschalten, falls dieser nicht den erwarteten Pegel hat. Vorteil der uC Lösung ist, dass man sich da in der Flexibilität austoben kann und, je nach eigenen Fähigkeiten, kann man Teile der Aufgabe in den uC oder eben in den Router verlagern. Entprellen, Schaltschwellen u.s.w. kann man in der Software lösen. Dafür besteht die Gefahr, dass das alles etwas mehr Energie benötigt und daher nicht mehr mit einem kleinen GoldCap Wochen lang auch ohne einen einzigen Sonnenstrahl auskommt. Und zuletzt besteht natürlich kein Einwand dagegen, das ganze mit einem ATmega32 auf einem Steckbrett aufzubauen, und mit 10mA und mehr mal alles auszuprobieren, bis es funktioniert und dann erst alles auf Strom sparen zu optimieren und in einen 2kB tiny mit 8 Pinnen zu flashen den man unter der Lupe auf das Router Board geklebt und verfädelt hat. Gruß Ulrich
> Es macht wenig Sinn, wenn man einen 9nA uC nutzt, wenn man diesen mit > einem billig Netzteil betreibt, dass selbst 1W in Wärme umsetzt. Ist Es gibt kein Netzteil. Es gibt nur einen Akku. (wohl ein typ18650 also irgenwas in der Groessenordnung 2.2Ah x N)
> Und zuletzt besteht natürlich kein Einwand dagegen, das ganze mit einem > ATmega32 auf einem Steckbrett aufzubauen, und mit 10mA und mehr mal > alles auszuprobieren, bis es funktioniert und dann erst alles auf Strom > sparen zu optimieren und in einen 2kB tiny mit 8 Pinnen zu flashen den > man unter der Lupe auf das Router Board geklebt und verfädelt hat. Danke für die Bestätigung, dies war auch mein Gedanke - erstmal probieren und dann auf sparsamkeit/kosten trimmen...
>> Also in einen Tiny85 (8pinner) paßt die USB-Lib und den gibt's auch >> schön stromsparend :-) > > USB war aber nicht gefordert, außerdem hat der Tiny85 mindestens einen Ich hadere noch. USB hat den Vorteil, das es geht ohne den Router zu öffnen. Allerdings glaube ich auf lange Sicht (bzw. wenn man es richtig machen will) kommt man ohnehin nicht drumrum. Wenn man fuer USB jedoch was in der Groessenordnung 48MHz braucht, halte ich das fuer overkill.
> Einen vollwertigen Router mit einem Kernel, der mit einer Linux-Zeit > umgehen kann. Er kann auch einfach errechnen, wie viele Sekunden von > jetzt bis zum nächsten Einschalten vergehen sollen. Jawoll. Wir haben sogar Internet und könnten den Wetterbericht der naechsten Tage zu Rate ziehen. (wenn also morgen intensiv Sonne scheint muessen wir nicht ganz so sparsam sein, als wenn wieder ein Regentag ist...) > Dann kann er diese Zeit in den uC senden und sich selbst herunter fahren > und ein FlipFlop resetten, dass seine eigene Versorgung frei schaltet. > Was fehlt: Ein uC, der via I2C die obigen Sekunden entgegen nimmt, mit > 32768Hz Uhrenquarz diese Sekunden über einen Timer abzählt und dann bei > 0 stoppt, einen Pin wechselt, dass der das FlipFlop wieder umschaltet > und den Router startet. I2C? laesst sich das per serieller "emulieren"? Oder spekulierst du darauf, das der Router das spricht?
Bastian Bittorf schrieb: > I2C? laesst sich das per serieller "emulieren"? Oder spekulierst du > darauf, das der Router das spricht? Mit an Sicherheit grenzender Wahrscheinlichkeit kann es der SoC im Router, denn nicht selten wird ein Teil der Hardware in so einem Gerät (z.B. das EEPROM für die MAC-Adresse oder ein Switch-Chip) über I²C angesprochen. Die Frage ist nur, ob und wie leicht die Signale auf dem Board zugänglich sind. Falls er es doch nicht kann oder die Pins nicht zugänglich sind, könnte man es immer noch per Bit-Banging auf zwei erreichbaren GPIO-Pins machen, alles nötige dazu ist im Linux-Kernel schon drin.
Zu I2C: Irgendwo war doch die Rede von DD-WRT? Da machen sie sogar SPI per Bitbanging um eine SD-Card für einen WEB-Server hinzu zu fügen. I2C ist im Grunde noch anspruchsloser, weil der Slave nicht der Clock des Masters folgen muss. Stattdessen darf der Slave bei jedem Bit die Clock aktiv fest halten, bis er das Bit gelesen hat (Bit-Stretching) oder die letzte Clock vor dem dann zu sendenden ACK fest halten (ACK-Stretching) oder eben so lange das ACK nicht senden, bis er wieder neue Daten aufnehmen kann (ACK-Polling). Gruß Ulrich
> Irgendwo war doch die Rede von DD-WRT? Da machen sie sogar SPI per > Bitbanging um eine SD-Card für einen WEB-Server hinzu zu fügen. I2C ist > im Grunde noch anspruchsloser, weil der Slave nicht der Clock des die reine Lehre: OpenWrt - tatsächlich scheint es leicht moeglich zu sein, dem Router I2C beizubringen (darauf wirds also hinauslaufen): http://pragti.ch/kippycam/Adding%20an%20I2C%20interface%20to%20the%20TL-WR703N.html
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.