Guten Abend, ich beschäftige mich seit längerem damit einen AIO-Pc mit Akku zu designen. Es geht mir erst mal lediglich um ein Theoretisches Szenario. Ich bin jetzt an den Punkt angekommen an dem Google allein nicht mehr hilft. Die Frage ist wie integriert man die Akkus am besten in das System? Mir geht es darum das der Akku Ladestand, die Gesundheit der Zellen, die Temperatur usw. vom System erkannt wird und auslesbar ist. Auch ein automatisches Herunterfahren wäre nicht schlecht, bezw. nicht startet wenn es dem Akku schlecht geht oder fast leer ist. Ich stelle mir das wie bei einem Laptop vor. Ich kenne das von meinem Dell der zeigt bei niedrigem Akku noch vor dem booten an: „Akku muss geladen werden!!!“ wenn dieser leer ist ;-). Es gibt ähnliche Systeme die mit Hilfe eines Embedded Controller den Akku überwachen und Informationen an das Hauptsystem schicken. Das Bios ist für die Daten vom Embedded Controller empfangsbereit. Bei dieser Herangehensweise frag ich mich worin der Vorteil besteht? Wie erkennt das OS den Akku Ladestand? Gibt es auf einem Normalem Atx Mainboard Schnittstellen, über die man einen Embedded Controller anschließen kann der die Akkus ins System integriert (auch für den Power-on self-test)? Wenn ja kann das Standard Bios überhaupt damit umgehen? Die andere Möglichkeit ist eine Usv-Platine mit entsprechender Software. Doch ich konnte bisher nicht herausfinden ob man das System starten kann wenn die Usv schon im Stromausfall-Modus ist? Hierbei wird wahrscheinlich beim Start nicht auf die Gesundheit oder Ladestand des Akkus geachtet? Mich würde es interessieren wie die Integration am besten wäre und was überhaupt geht?
Mandalore schrieb: > Wie erkennt das OS den Akku Ladestand? Z.B. via ACPI. Mandalore schrieb: > Gibt es auf einem Normalem Atx Mainboard Schnittstellen, über die man > einen Embedded Controller anschließen kann der die Akkus ins System > integriert (auch für den Power-on self-test)? Z.B. LPC-Bus, ob man da bei einem konkreten MB physikalisch dran kommt ist eine andere Frage. Mandalore schrieb: > Wenn ja kann das Standard Bios überhaupt damit umgehen? Kommt darauf an, ob der Hersteller das vorgesehen hat. Ansonsten mußt Du es halt selber entsprechend erweitern/konfigurieren. Oder was eigenes bauen, z.B. aus TianoCore oder coreboot.
Mandalore schrieb: > Ich kenne das von meinem Dell der zeigt bei > niedrigem Akku noch vor dem booten an: „Akku muss geladen werden!!!“ > wenn dieser leer ist ;-). Bildschirm anschmeissen kostet erheblich Strom, den leerer Akku eher nicht mag. Wie dachtest Du Dir das mit der Stomversorgung? ATX braucht 12V, 5V und 3,3Volt. Und da ist der Bildschirm noch nichtmal dabei. Die Ströme bei Desktop Boards und Komponenten sind auch nicht grade angenehm für Akkus... Du bräuchtest also eine Art Custom ATX Netzteil. Dort würde ich einen kleinen µC einbauen, der die Akku Versorgung steuert und sich beim Mainboard ganz normal als USV über USB meldet. Unterhalb von x% Akku schaltet man das System nicht mehr ein sondern lässt höchstens eine LED blinken. Externe 230V USV dürfte eheblich preiswerter werden, wenn auch wegen der Bleiakkus verdammt schwer.
Hi, ich war jetzt leider eine ganze Zeit anderweitig beschäftigt und kann erst jetzt wieder am Projekt weitermachen. guest schrieb: > Kommt darauf an, ob der Hersteller das vorgesehen hat. > Ansonsten mußt Du es halt selber entsprechend erweitern/konfigurieren. > Oder was eigenes bauen, z.B. aus TianoCore oder coreboot. Ok, dass dachte ich mir schon. Mein Anspruch wahr, dass das Bios Orginal bleiben kann. Aber dann wirds halt so eine Lösung. Der LPC-Bus hat leider das Problem, dass dieser keine Schnittstelle nach außen hat. Deshalb ist die Frage, ob es eine andere geeignete Schnittstelle gibt? Eignet sich villeicht ein pcie×4 port? Jim M. schrieb: > Wie dachtest Du Dir das mit der Stomversorgung? ATX braucht 12V, 5V und > 3,3Volt. Und da ist der Bildschirm noch nichtmal dabei. Der Plan ist eine DC-Atx-psu zu benutzen wie diese: https://www.hdplex.com/hdplex-400w-hi-fi-dc-atx-power-supply-16v-24v-wide-range-voltage-input.html Diese verteilt den Strom der aus dem Akku kommt. Jim M. schrieb: > Dort würde ich einen > kleinen µC einbauen, der die Akku Versorgung steuert und sich beim > Mainboard ganz normal als USV über USB meldet. Den Vorschlag finde ich gut, danke dafür. Allerdings würde ich eine Lösung bevorzugen, bei der der der Akku mit dem µC Teil des Systems ist. Ab dem drücken des Power-Button soll der Akku kontroliert und überwacht werden. Gegebnfalls soll der Systemstart verhindert werden bzw. der Computer ausgeschalten werden, wenn etwas mit den Zellen des Akkus nicht stimmt.
Jim M. schrieb: > Die Ströme bei Desktop Boards und Komponenten sind auch nicht grade > angenehm für Akkus... Die 400W, die mein PC beim Spielen zieht, sind zumindest nicht allzu lange aus einem Akku herauszubekommen, den man noch ohne Sackkarre bewegen kann. @TO: Erst schreibst du von AiO - das sind meistens Laptops ohne Akku und mit Desktop-Bildschirmen, danach was von einem ATX Mainboard und schlägst ein 400W Netzteil vor. Was soll es denn werden? Mandalore schrieb: > Eignet sich villeicht ein pcie×4 port? Spontan würde ich sagen: Nein. Zumindest nicht besser als USB oder RS232. An letztere kannst du einen µC hängen und deinen eigenen Treiber für Windows schreiben. So machen das die meisten USV, die per USB/Netzwerk angeschlossen werden. Die Alternative dürfte wohl sowas wie der SMBUS sein. Aber da kommt man maximal bei Serverboards ran. Hast du dir schon mal Gedanken zu der Größe des Akkus gemacht? Ein Desktop-Monitor zieht so um die 30W im Betrieb, ein Laptopmonitor gerade mal um die 5W - nur zum Vergleich. Ähnlich sieht es aus mit dem Stromverbrauch im Idle, Desktop Mainboards + CPUs + Grafikkarten ziehen da locker mal 60-80W im Leerlauf, Laptops eher so 2-5W. Dementsprechend müsste der Akku im Leerlauf schon mehr Leistung bringen, als ein Laptopakku unter Volllast.
Mandalore schrieb: > Wie erkennt das OS den Akku Ladestand? Stichwort ACPI Du musst jetzt zwei Dinge trennen. 1. die Hardwaremäßige Anbindung der Akkzuelektronik über LPC, SMB oder was auch immer 2. die System-/Softwareschnittstelle für die Betriebssystemeinbindung. Für 2. gibt es ACPI. Das ist genau der Punkt, an dem Du Bios und Betriebssystem solche Dinge wie Akkuzustände, Powerstates, Powerbutton,... bekannt machst. Wenn Du dieses Projekt erfolgreich zuende führen willst, dann MUSST du dich zwingend mit ACPI auseinander setzen und die entsprechenden Dinge im BIOS implementieren. Das ist der vorgesehene Weg für einen Systemhersteller bzw Systemintegrator. Hier ist die Spec: http://www.acpi.info/DOWNLOADS/ACPIspec50.pdf > Gibt es auf einem Normalem Atx Mainboard Schnittstellen, über die man > einen Embedded Controller anschließen kann der die Akkus ins System > integriert (auch für den Power-on self-test)? Wenn ja kann das Standard > Bios überhaupt damit umgehen? Üblich ist SMB, das eigentlich immer irgendwie implementiert ist. LPC wäre auch eine Möglichkeit. Aber das ist erst der zweite Schritt. Dein eigentliches Problem ist das ACPI. Das ist nämlich nicht ganz ohne, und der nicht zu ungehende Zwang, das BIOS anzupassen, wird die Auswahl der Mainboards einschränken. Auch das ist etwas, was DU vorher wissen musst. > Die andere Möglichkeit ist eine Usv-Platine mit entsprechender Software. Das ist nicht das gleiche. Darüber kannst Du beispielsweise nicht das Betriebssystem steuern oder verhindern, dass zu viel Leistung gezogen wird. Diese granulare Steuerung geht nur über ACPI. fchk PS: Blättere mal auf Seite 490: "An ACPI-compatible Smart Battery subsystem consists of: • An SMB-HC (CPU to SMB-HC) interface • At least one Smart Battery • A Smart Battery Charger • Either a Smart Battery System Manager or a Smart Battery Selector if more than one Smart Battery is supported In such a subsystem, a standard way of communicating with a Smart Battery and Smart Battery Charger is through the SMBus physical protocols. The Smart Battery System Manager or Smart Battery Selector provides event notification (battery insertion/removal, and so on) and charger SMBus routing capability for any Smart Battery subsystem. A typical Smart Battery subsystem is illustrated below:" ... und dann folgen 100 Seiten, wie Du das genau zu implementieren hast.
:
Bearbeitet durch User
qwerzuiopü+ schrieb: > Spontan würde ich sagen: Nein. Zumindest nicht besser als USB oder > RS232. An letztere kannst du einen µC hängen und deinen eigenen Treiber > für Windows schreiben. So machen das die meisten USV, die per > USB/Netzwerk angeschlossen werden. Das sind keine Treiber, sondern bloß Dienste. Sprich: Anwendungen, die im Userspace laufen, bloß halt im Hintergrund und ohne interaktive Benutzeranmeldung. Sowas ist sehr viel einfacher als ein Treiber zu schreiben. > Die Alternative dürfte wohl sowas wie der SMBUS sein. Aber da kommt man > maximal bei Serverboards ran. Man könnte das Tachosignal eines unbenutzten Lüfteranschlusses verwenden, das könnte dann sogar schon im BIOS/UEFI für eine Fehlermeldung sorgen. Natürlich aber mit einem falschen/irreführenden Fehlertext.
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.