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.
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.
