Hallo, Ich habe gerade ein "witziges" Problem. Vielleicht kennen hier einige den Voltcraft PM-60V/20A, ein billiger (60€) Gleichstromzähler für den Modellbau etc. Eigentlich ein feines Teil, loggt automatisch Spannung, Strom und Zeit sowie ein paar min./max. Werte und errechnet daraus z.b. die Akkukapazität etc. Nun verfügt das Dingen noch über einen serielle Schnittstelle, über die sich die geloggten Daten auf den PC laden und recht übersichtlich plotten lassen. Allerdings läuft die Zeit auf dem Gerät zu langsam, sobald die Schnittstelle verbunden ist (und somit die Werte auf dem Software Display aktualisiert werden). Während des Downloads steht die Uhr ganz. Sobald der Stecker gezogen ist, passt die Zeit, sonst verliert sie je Minute 15-17 Sekunden!!! Das führt natürlich zu völlig wirren Kapazitäten, die da rauskommen. Habe das gemerkt, als ich zwei neue Akkupacks "vermessen" habe. Das eine hatte plätzlich 20Wh weniger Kapazität als das, das ich offline gemessen habe. Da müssen mal wieder äußerst pfiffige Programmierer am Werk gewesen sein! Hat das Problem schon mal wer gehabt und evtl. eine alternative Firmware gezaubert? Sollte eigentlich kein großes Dingen sein. Ein offizielles Firmwareupdate habe ich nicht finden können. Ansonsten das hier nur als Hinweis für andere, die ähnliche Überraschungen mit dem Teil erleben. Wird auch unter anderem Label verkauft. Euer Akkutester
Wie soll denn bitteschön die RTC durch eine RS232 beeinflusst werden? Und was soll da ein Firmwareupdate bringen? Experten gibt es hier...
Thorsten Legat schrieb: > Wie soll denn bitteschön die RTC durch eine RS232 beeinflusst > werden? Wer sagt dass die interne Uhr über eine richtige RTC läuft, und da nicht irgendwo ein Task läuft:
1 | while (1) { seconds++; sleep (1); } |
und der halt weniger Zeit bekommt, wenn nebenher noch was anderes läuft? Man ist allgemein viel zu optimistisch bzgl. der Qualität von Industrie-Software, da ist unglaublich viel zusammengefrickelter Schrott drunter.
Bei einem Markenhersteller gehe ich ja mal davon aus, dass das nicht so billig gemacht ist. Habe ein Multimeter von denen, das geht sehr sehr genau. Die sitzen immerhin in De. Wie sollte der denn messen und anzeigen auf dem LCD, wenn er die ganze Zeit wartet? Ich glaube eher, der TE hat eine falsche Baudrate eingestellt. Zu hoch. Und dann passt das Timing nicht mehr.
Thorsten Legat schrieb: > Bei einem Markenhersteller gehe ich ja mal davon aus, dass das nicht so > billig gemacht ist. Haha, so wie die Software bei VW? Oder die von Microsoft (zum Glück mittlerweile gebessert)? Software-Struktur sieht man nicht, da wird gerne gepfuscht. Aber irgendwann fällts dann doch auf. Man schaue doch mal nur hier im Forum, was für Frickellösungen als "Produktiv" genutzt werden. Das fängt ja shcon damit an, dass unbedingt die "einfachsten" (am wenigsten mächtigsten) Tools verwendet werden müssen, um sich den Lernaufwand zu sparen. Thorsten Legat schrieb: > Die sitzen immerhin in De. Und das heißt... was? Dass die Entwicklung nicht nach Indien outgesourced wurde? Dass aus deutschen Hochschulen nur die perfekten Entwickler kommen, und langfristig planende Manager? Wenn ein Programm zu funktionieren scheint, wird es doch ausgeliefert, und bloß kein Gedanke daran verschwendet, ob die Grundidee nicht doch eine Katastrophe ist. Thorsten Legat schrieb: > Wie sollte der denn messen und anzeigen auf dem LCD, wenn er die ganze > Zeit wartet? Kann doch sein, dass die ein RTOS verwenden. Ein Task hat die o.g. Schleife, ein anderer macht den UART, und wenn letzterer beschäftigt ist, geht dem anderen die Zeit aus. Thorsten Legat schrieb: > Ich glaube eher, der TE hat eine falsche Baudrate eingestellt Die Baudrate des UART soll die RTC beeinflussen? Das klingt ja nach noch seltsamerer Programmierung. Kleine Anekdote: An meiner Hochschule gab es als Forschungsprojekt eine Art Frequenzzähler für eine besondere Anwendung. Dieser wurde auf einem AVR umgesetzt. Weil es aber zu anstrengend war, im Datasheet nahczulesen wie der Input Capture funktioniert, wurde das halt in Software gemacht durch fleißig Zyklen zählen usw. Wenn man also auf die Idee kommt noch eine andere Funktion hinzuzufügen - Kommunikation per UART z.B. - kommt das Timing durcheinander. Das Projekt war natürlich super und kam gut an. Nur weil man das vernünftig machen kann - mit Input Capture - heißt das noch lange nicht, dass das auch gemacht wird!
Akkutester schrieb: > Allerdings läuft die Zeit auf dem Gerät zu langsam, sobald die > Schnittstelle verbunden ist (und somit die Werte auf dem Software > Display aktualisiert werden). Während des Downloads steht die Uhr ganz. Dann wird wohl ein delay(1000) die Länge der Sekunden bestimmen und die serielle Übertragung nicht asynchron ablaufen.
Dr. Sommer schrieb: > Kann doch sein, dass die ein RTOS verwenden. Ein Task hat die o.g. > Schleife, ein anderer macht den UART, und wenn letzterer beschäftigt > ist, geht dem anderen die Zeit aus. Freunde, es geht um dieses Gerät: https://www.conrad.de/de/voltcraft-pm-60v20a-dc-leistungsmessgeraet-pm-60v20a-spannung-500-6000-vdc-000-6000-vdc-mit-externer-spannungsversorgung-strom-001-20-a-101668.html Da drin muckelt ein offensichtlich räudig programmierter PIC irgendwas vor sich hin, kein RTOS. Wär schön, wenn ein sicher vorhandener Timer auch genutzt würde. Es dürfte aber wirklich eher eine einfache wait Funktion in der Schleife sein, evtl. angepasst auf die ADC Messungen und die LCD Ausgabe. Denn nur damit passt die Zeit recht genau, soweit ich das bisher beobachten konnte. Wieso für die Ausgabe der paar Daten auf den UART 17(!) Sekunden je Minute vertrödelt werden können, ist mir allerdings völlig schleierhaft. Wie schafft man denn sowas wohl? Oder ist das ein Feature vom PIC? Kenne persönlich nur die AVRs und da wüsste ich kaum, wie das gehen sollte.
Akkutester schrieb: > Da drin muckelt ein offensichtlich räudig programmierter PIC irgendwas > vor sich hin, kein RTOS. Gibt's dafür kein RTOS? Damit kann man doch so einfach und schnell programmieren (hust)! Akkutester schrieb: > Wieso für die Ausgabe der paar Daten auf den UART 17(!) Sekunden je > Minute vertrödelt werden können, ist mir allerdings völlig schleierhaft. Gar kein problem, wenn man synchron sendet, d.h. nach jedem byte in einer while-Schleife wartet bis es weg ist (busy waiting). Die allermeisten Programme hier im Forum sind doch genauso geschrieben. Wenn man jetzt viele Bytes sendet, und die meiste Zeit des Prozessors mit Warten auf Fertigstellung vertrödelt, passiert genau sowas, völlig unabhängig von AVR / PIC / whatever. Besonders beliebt ist dieses Vorgehen auch bei den LCD-Routinen oder SD-Karten-Ansteuerungen, die mit Warteschleifen das Programm blockieren.
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.