Hallo, kennt jemand von euch eine C Library für Microchip PIC Mikrocontroller vom Typ 16Fxxx ? Will mit einem PIC16Fxxx als Master mit MODBUS Protokolle kommunizieren. Danke David
David schrieb: > Hallo, > > kennt jemand von euch eine C Library für Microchip PIC Mikrocontroller > vom Typ 16Fxxx ? > Will mit einem PIC16Fxxx als Master mit MODBUS Protokolle kommunizieren. > > Danke > David http://www.opensourcepic.com/modbus.php https://www.embedded-experts.at/en/freemodbus/about/ http://www.sourceboost.com/Products/BoostC/ExampleCode.html Für die 18F Pics ist das Angebot besser, weil jene in der Regel wesentlich mehr SRAM aufweisen. Sonst mußt Du versuchen, selber etwas auf die Beine zu stellen. PIC16 haben in der Regel wesentlich weniger SRAM. Da MODBUS ziemlich Register intensiv ist, ist das höchstwahrscheinlich ein No-Go mit den PIC16. Ich bin der Meinung, daß es sich auf dem PIC16 nicht wirklich lohnt. Ich würde da eher einen ATMEGA1284er nehmen wollen oder irgendeinen Cortex. Dann kann man es ordentlich implementieren. Ich machte vor Jahren einen Modbus Sensor mit freeMB auf einem STM32F103. Das funktionierte absolut ordentlich. Der Stack kommuniziert über Funktionszeiger und Callbacks mit der Anwendung. Das funktioniert sehr zuverlässig. Die Modbus Engine lebt da total im Hintergrund. für Arduinos gibt es übrigens MB Bibliotheken zum Ausprobieren. Vielleicht probier diese mal aus um auf den 8-bit MB Geschmack zu kommen. Naja, vielleicht findet sich noch etwas wie gewünscht auf dem Präsentierteller für 16F...
Danke Gerhard, das hatte ich schon befürchtet , dass es für den PIC16 nichts gibt. Will nur ein paar Register (max. 5) eines Wechslerichters lesen bzw. beschreiben, insofern würde ein 16er wohl völlig ausreichen. Die Microchip PICS finde ich super und gradlinig, musste aber in der Vergangenheit immer wieder auf Arduino & Co umsteigen, weil dort die Libs existieren. Ich poste mal noch bei den Softwareexperten, ob die für den Modbus mit PIC noch was auf Lager haben. Danke David
:
Bearbeitet durch User
Gerhard O. schrieb: > Da MODBUS ziemlich Register intensiv ist Kommt drauf an, was man damit macht. Was genau meinst Du überhaupt mit "register intensiv"? Man muss ein Telegramm zusammenbasteln, das über eine serielle Schnittstelle absenden, die Antwort empfangen und auswerten. Mehr isses nicht. Wenn feststeht, welche Register im Modbus-Gerät ausgelesen werden sollen, und welche Adresse das Gerät hat, kann man die Anfragetelegramme auch einfach als Konstanten-Array im Flash ablegen. Eine konstante Bytefolge zu senden sollte selbst für den kleinsten aller µC kein Thema sein. Die Antwort z.B. beim Auslesen eines Holding Registers muss nicht sehr lang sein (man kann die Größe durch die Anzahl der angeforderten Register selbst beeinflussen, liest man nur ein einzelnes Register, erhält man auch nur ein einzelnes Register). Wenn man der seriellen Verbindung vertraut, kann man die CRC-Prüfung der empfangenen Telegramme auch unter den Tisch fallen lassen. Das ist zwar "schlunzig", aber in einer bekannten und definierten Umgebung durchaus tolerierbar. Wenn man mit vordefinierten Telegrammen aus dem Flash-Rom arbeitet, muss man sich zur Laufzeit auch nicht um deren CRC kümmern, die steht einfach vorberechnet im Flash. Und damit genügen auch 16 oder 32 Byte Empfangspuffer für die serielle Schnittstelle, und praktisch jeder µC sollte das schaffen. Aufwendiger wirds halt, wenn man zur Laufzeit Geräte- und Registeradressen festlegen will, dann muss man CRC zur Laufzeit berechnen, aber auch das frisst nicht unendlich viel Speicher (die nötige Tabelle kann ins Flash).
Harald K. schrieb: > dann muss man CRC zur Laufzeit berechnen, aber auch das frisst nicht > unendlich viel Speicher (die nötige Tabelle kann ins Flash). Viele Cortex-M haben eine CRC-Beschleuniger-Hardware 😉
Niklas G. schrieb: > Viele Cortex-M haben eine CRC-Beschleuniger-Hardware PIC16Fxxx haben Cortex-M Prozessoren? Hat man den beschnitten, damit er nur noch acht bit hat? So wie die 386SX?
Rahul D. schrieb: > PIC16Fxxx haben Cortex-M Prozessoren Gerhard hat doch schon vorgeschlagen einen Cortex zu nehmen: Gerhard O. schrieb: > oder irgendeinen Cortex Ich wollte lediglich als Argument angeben, dass die CRC-Einheit vieler Cortex-MCUs hier ebenfalls sehr nützlich wäre.
... Kommt drauf an, was man damit macht. Was genau meinst Du überhaupt mit "register intensiv"? Man muss ein Telegramm zusammenbasteln, das über eine serielle Schnittstelle absenden, die Antwort empfangen und auswerten... Bei mir waren über 100 MB Register involviert. MB wurde auch zur Kalibrierung und alle Einstellungen benützt. Ansonsten gebe ich Dir recht, daß man es machen könnte, solange es hineinpasst. Bei nur einigen Registern ginge es bestimmt. CRC wie von Dir vorgeschlagen in Flash Tabellen angelegt. Ob da aber ein 16F887 mit 368B ausreichen würde? Man könnte ja versuchen, schon existierenden MB code zu portieren oder darauf stützen. Ist halt eine Frage der Zeit. Wenn es schnell gehen soll, dann ist wahrscheinlich Arduino MB "the way to go". FreeMB ist halt sehr aufwendig und kompliziert. Funktioniert aber auf einem Cortex auch sehr schön.
Niklas G. schrieb: > Gerhard hat doch schon vorgeschlagen einen Cortex zu nehmen: Jemandem einen Cortex als "Alternative" für einen PIC vorzuschlagen, hat was von Kanonen und Spatzen. Modbus wurde 1979 "ins Leben gerufen" (siehe Wikipedia). Man sollte die Kommunikation also auch mit einem PIC umsetzen können. Vielleicht nicht unbedingt mit dem kleinsten eine komplette Fertigungsstraße, aber ein paar Register eines Wechselrechters solten kein Problem darstellen. Eiunige arm-Controller haben sogar schon fertige Modbus-Interface an Bord, die sich um die Timing-Geschichten und RS486-Steuerung kümmern. [OT] Der Thread wurde ja auch nur aus Faulheit gestartet, weil sich der Threadstarter lieber auf eine Bibliothek verlässt, anstatt sich mit der Thematik auseinander zu setzen. Ich bin da der gleichen Meinung wie Harald K., dass man die Minimalanforderungen auch mit dem PIC16F umsetzen kann, wenn man nur feste Abfragen etc. verwendet. Das därfte auf jeden Fall einfacher sein, als sich in einen Cortex-M einzuarbeiten. Soooo schwer ist Modbus auch wieder nicht; und Checksummen für Abfragen kann man sich (online) berechnen lassen. [/OT]
...Jemandem einen Cortex als "Alternative" für einen PIC vorzuschlagen, hat was von Kanonen und Spatzen... Bei uns war das ein kommerzielles Firmenprojekt. Früher machten wir ein kleineres MB Projekt auf einem PIC18 mit 3.x kB an SRAM. Das reichte natürlich vollkommen aus. Das funktionierte sogar sehr ordentlich. Nur wäre für uns aus unserer Sicht kein PIC16 eingefallen. Aber versuchen könnte man es. Hat halt damit seine Grenzen. ...Modbus wurde 1979 "ins Leben gerufen" (siehe Wikipedia)... Naja. Aber viele der damaligen Mikroprozessorschaltungen hatten auch ordentlich RAM. Gegen MB Cortex ist wenig einzuwenden. Das funktionierte alles einfach zügig und gut. Warum den nicht? Es war 2010 und nicht 1978. Da war insgesamt der Cortex einfach die bessere Wahl, insofern man auch die meßtechnischen Belange berücksichtigen muß. Und Erfahrungen hatten wir schon mit Cortex. Einarbeiten war da nicht mehr notwendig. Es gab Atollic und CooCox, die beide nicht schlecht funktionierten. Für die Anwendung des Wechselrichters würde ich es auch mit Arduino MB machen. Das könnte gut in einem Abend fertig sein.
:
Bearbeitet durch User
Gerhard O. schrieb: > Bei uns war das ein kommerzielles Firmenprojekt. Ich käme nie auf die Idee, was mit Modbus als Hobby zu machen. > Früher machten wir ein kleineres MB Projekt auf einem PIC18 mit 3.x kB > an SRAM. Das reichte natürlich vollkommen aus. Das funktionierte sogar > sehr ordentlich. Nur wäre für uns aus unserer Sicht kein PIC16 > eingefallen. Aber versuchen könnte man es. Hat halt damit seine Grenzen. > > ...Modbus wurde 1979 "ins Leben gerufen" (siehe Wikipedia)... > > Naja. Aber viele der damaligen Mikroprozessorschaltungen hatten auch > ordentlich RAM. Ich habe keine QUellen, aber müsste Modbus nicht auch "problemlos" von 8051er unterstütz werden? > Gegen MB Cortex ist wenig einzuwenden. Das funktionierte alles einfach > zügig und gut. Warum den nicht? Es war 2010 und nicht 1978. Da war > insgesamt der Cortex einfach die bessere Wahl, insofern man auch die > meßtechnischen Belange berücksichtigen muß. Wir verwenden in der Firma AVR als Modbus Slaves oder kleine Master. Die großen Master für diverse Slaves werden mit STM32F4 oder H7 umgesetzt. > Für die Anwendung des Wechselrichters würde ich es auch mit Arduino MB > machen. Das könnte gut in einem Abend fertig sein. Ich erledige privat alles mit AVR oder Arduinos (u.a. ESP). PICS haben bei mir seit der Jahrtausendwende "Hausverbot". Falls jemand den Grund dafür wissen möchte: PICs (16F84 oder so) habe ich damals diverse mit dem LudiPipo verflasht, die nicht wiederbelebar waren - AVR noch keinen.
Gerhard O. schrieb: > Bei mir waren über 100 MB Register involviert. MB wurde auch zur > Kalibrierung und alle Einstellungen benützt. Nun, es kommt eben drauf an, was man damit macht. Vielleicht verrät ja David, was er im einzelnen machen will, und mit welchem Modbus-Gerät.
Was ich manchmal nicht verstehe: warum wollen Hobby-Leute so oft sehr billige und einfache Controller benutzen? Wenn ich eine Serienproduktion mit 1000 Einheiten habe, dann mag sich das lohnen. Doch wenn ich nur für mich ein Gerät programmiere, dann ist mir egal, ob der Controller 10 Euro mehr kostet, und evtl 100K überflüssigen Ram hat. Ich möchte einfach nur schnell das Problem lösen. Da gebe ich dann lieber ein paar Euro mehr aus, und nehme z.B. ein Arm-Prozessor mit CRC, als dass ich eine Woche länger an dem Code herum prokele. Mit der gesparten Zeit kann ich besseres anfangen.
Peter schrieb: > Was ich manchmal nicht verstehe: warum wollen Hobby-Leute so oft sehr > billige und einfache Controller benutzen? Weil sie sie kennen, weil sie das nötige Entwicklungssystem haben, und weil sie einfacher zu verarbeiten sind als modernere und leistungsfähigere Controller. PIC16F gibts im DIP-Gehäuse, das kann man auf 'ne Lochrasterplatine löten oder in ein Frickelboard stecken, und die Dinger laufen unkompliziert mit 5V. Typische Cortex-ARMe kommen in irgendwelchen Fine-Pitch-SMD-Gehäusen daher, und müssen entweder auf eine selbst zu designende Platine gelötet werden oder aber auf irgendein Board gelötet gekauft werden. Schon die Taktinitialisierung eines typischen Cortext-ARMs ist deutlich komplizierter und trickreicher als das, was so ein Simpel-PIC braucht. Klar, für das gibt es auch schicke Softwarepakete, die einem viel Arbeit abnehmen, aber die muss man auch erstmal erlernen. Und wenn man über die Jahre schon das eine oder andere Projekt mit so einem PIC oder AVR umgesetzt hat, dann kennt man das Ding halt, und muss sich nicht in was völlig anderes, völlig neues einarbeiten. Oft reichts halt auch. Daß gerade der Wechsel zu einem Cortex-ARM einem wie ein Befreiungsschlag vorkommen kann, weil man endlich viel mehr Speicher nutzen kann, viel leistungsfähigere Peripherie nutzen kann und viel mehr Performance hat, trifft zwar zu, erfordert aber eben beim Umstieg eine entsprechend herbe Lernkurve.
Peter schrieb: > Was ich manchmal nicht verstehe: warum wollen Hobby-Leute so oft sehr > billige und einfache Controller benutzen? Verstehe ich. Geht mir genau so. Harald K. schrieb: > Weil sie sie kennen, weil sie das nötige Entwicklungssystem haben, und > weil sie einfacher zu verarbeiten sind als modernere und > leistungsfähigere Controller. Naja, kennen tut der TO den PIC scheinbar auch nicht wirklich. Ich meine für Modbus (ich gehe hier von RTU aus) braucht man bisschen UART und nen Pin für die Richtungsumschaltung. Das sind eine der ersten Dinge was man mit einem Controller macht. Das Protokoll sitzt ja nur auf den Daten auf. Ein Arduino unterstützter Controller hätte fertige Libraries. Von 8 bis 32 Bit. Von DIP bis QFN. Die Frage warum es ausgerechnet ein PIC sein soll ist also schon gerechtfertigt meiner Meinung nach.
:
Bearbeitet durch User
Harald K. schrieb: > Weil sie sie kennen, weil sie das nötige Entwicklungssystem haben, und > weil sie einfacher zu verarbeiten sind als modernere und > leistungsfähigere Controller. PIC16F gibts im DIP-Gehäuse, das kann man > auf 'ne Lochrasterplatine löten oder in ein Frickelboard stecken, und > die Dinger laufen unkompliziert mit 5V. Genauso ist es. Harald hat das absolut richtig beschrieben. Die PIC Familie (von PIC12Fxx bis inkl. PIC16Fxx) habe ich schon oft benutzt, Compiler und Brenner sind vorhanden und kaputt ist mir von diesen auch noch keiner gegangen - bin sehr zufrieden damit. Bin Hobbybastler , kein Profi sonst würde ich auch mehr auf Wirtschaftlichkeit setzen, aber so finde ich für mich PICs als erste Wahl, wenn technisch einsetzbar und muss mich nicht je nach Hobbyprojekt ständig in einen neuen Controller einarbeiten und die passende Umgebung (Compiler, Programmer etc.) kaufen und aufbauen. Was habe ich damit vor ? Wie oben schon erwähnt einfahc einen Microwechslerichter über nacht derart steuern/regeln, dass er (im Batteriebetrieb) Akkuleistung nur in soweit verbrät, wie sie im Haushalt über Nacht benötigt wird. Der WS ermöglicht über MODBUS und RS485 die abgebbare Leistung flexibel einzustellen. Ein Controller (hooffe, es klappt mit dem PIC) bekommt an einem Port die iNfo, wie viel Leistung er einspeisen soll, und er PIC soll dann lediglich in ein Register des WS die max Wirkleistung reinschreiben. Dabei werden wohl nur nur eine Handvoll Werte nötig sein, da ich den Verbrauch über Nacht gut einschätzen kann - jenachdem was läuft kommen da nicht viele Werte in Frage. WS: Modbus RTU Protokoll, RS485 als Schnittstelle und als "Wandler von RS485 auf USB oder TTL" - beides wäre möglich, je nachdem was einfacher wäre- habe ich entsprechende kleine "Hardware-proxys", die dann zwischen WS und PIC geschaltet werden können. Die Frage ist halt nur, ob Arduino hier nicht die bessere Wahl wäre (Arduino Brenner und Compiler sind auch vorhanden, aber erfordern mehr Tamtam drumherum)... Aber auch für den Arduino habe ich noch nicht wirklich passendes gefunden , gibt viel Geschriebens aber passt nicht so ganz... zumindest das, was ich bislang gefunden habe
:
Bearbeitet durch User
David schrieb: > WS: Modbus RTU Protokoll, RS485 als Schnittstelle und als "Wandler von > RS485 auf USB oder TTL" Nee, USB willst Du nicht verwenden. Du brauchst einen RS485-Treiber wie z.B. MAX485*, der kommt direkt an die RX/TX-Pins Deines µC, und zusätzlich kommt die Sender-/Empfänger-Umschaltung des RS485-Treibers an einen I/O-Pin Deines µC. Dein Programm muss unmittelbar nach dem Versenden eines Telegrammes von Sende- auf Empfangsbetrieb umschalten, je nachdem wie die UART aufgebaut ist, kannst Du entweder einen Interrupt dafür nutzen (der ausgelöst wird, wenn das Sendeschieberegister leer ist) oder aber benötigst einen Timerinterrupt, der eine Byte-Zeit nach dem Übertragen des letzten zu sendenden Bytes in die UART ausgelöst wird. Das ist es dann aber auch schon. Was die Verdrahtung mit dem Modbus-Gerät betrifft, so musst Du zwei Datenleitungen (A und B) und Masse verdrahten, und gegebenenfalls an einen Leitungsabschlusswiderstand zwischen A und B denken, das sind üblicherweise 120 Ohm. *) https://www.analog.com/en/products/max485.html Es gibt zahllose Alternativen von allen möglichen Herstellern.
Harald K. schrieb: > Was die Verdrahtung mit dem Modbus-Gerät betrifft, so musst Du zwei > Datenleitungen (A und B) und Masse verdrahten, und gegebenenfalls an > einen Leitungsabschlusswiderstand zwischen A und B denken, das sind > üblicherweise 120 Ohm. Die Verdrahtung ist schon komplett auf diesem "proxy" vorhanden (würde dazu einen "RS485 To TTL UART Serial Port To RS485 Converter Function Module Stable Module" nutzen (https://www.ebay.de/itm/185943998950?_trkparms=amclksrc%3DITM%26aid%3D777008%26algo%3DPERSONAL.TOPIC%26ao%3D1%26asc%3D270962%26meid%3Df5dd7d0ca5e9401383015169d5a67a85%26pid%3D101949%26rk%3D1%26rkt%3D1%26itm%3D185943998950%26pmt%3D1%26noa%3D1%26pg%3D4375194%26algv%3DRecentlyViewedItemsV2WithMLRPbooster%26brand%3DMarkenlos&_trksid=p4375194.c101949.m162918&_trkparms=parentrq%3A194157711910a54828aa4ecaffff588e%7Cpageci%3A9bf4fca9-51bc-11ef-9ffa-a61c7461a8b7%7Ciid%3A1%7Cvlpname%3Avlp_homepage) Warum sollte ich aber noch auf Empfangsbetrieb umschalten, wenn ich dem WS vertraue, dass er die Daten korrekt empfangen und umgesetzt hat (sehe ich dann auch auf dem WS Display). Oder setzt der Slave beim MODBUS den Empfang /Befehl nicht um, wenn der Master (PIC) die Rückantwort nicht irgendwie nochmal empfängt ? Und wenn ich duie wenigen Telegramme fest abspeichern würde und es einmal funktioniert, dann müsste es auch immer wieder funktionieren.. wieso dann auf dem Master nochmal was empfangen ?
:
Bearbeitet durch User
Warum aber soll es ein 16F sein und nicht ein 18F? Da hat man zahlreiche Vorteile. Wir machten w.g. auch eine MB Anwendung mit PIC18 und funktionierte ausgezeichnet. Für 18F gab es zumindest früher einen Port für freeMB. Oder man schreibt sich was Einfaches selber. Bei mir war der Cortex aus meßtechnischen und Berechnungsgründen die bessere Wahl, weil sehr viel FP gerechnet werden mußte und da tut sich der Cortex leichter und macht es schneller. Ich traue mir zu eine bescheidene MB Sache auch auf einem 16F zum laufen zu bringen. Ich kenne PICs gut, weil ich über fünfundzwanzig Jahre damit in der Firma kommerziell entwickelt habe. Aber Cortexe haben auch ihre Existenzberechtigung. Abgesehen davon kann man mit Erfahrung so ziemlich alles mit allen möglichen verschiedenen uC machen. Für Hobby ziehe ich aus Bequemlichkeit (um nicht Faulheit zugeben zu müssen) das Arduino Ökusystem vor, weil man ziemlich viel Ressourcen hat. Man muß ja nicht unbedingt nur mit fremden Libs arbeiten. Man kann auch dort Bare Metal arbeiten oder eine Kombination. Ich bin mit einigen 8-bit uC Familien vertraut und konnte so ziemlich alles Portieren, falls es zweckmäßig war. Früher machte ich auch hobbymässig alles mit PICs. Aber da mußte ich mir die HW immer zuerst selber bauen. Heute kriegt man alle möglichen uC Bord Ausstattungen. Das gab es damals heute nicht. Bei einfacheren Projekten greife ich mir lieber einen neuen Nano oder Pro-Mini oder sonst irgendwas, stecke ihn an den PC und kann loslegen. Ging früher nur mit mehr Arbeitsaufwand. Davids Anwendung würde ich persönlich mit einem 4809er Arduino machen. MB Lib und den Rest mit Terminal Parametrisierung. Der hat dann bequemerweise, ungleich dem AVR Nano, zwei Serial Ports zur Verfügung. Einen für RS485 und USB für Teraterm. Und schon kann man mit dem Wechselrichter spielen. Sonst ließe sich stand-alone auch noch LCD und Bedienungsknöpfe vorstellen. Die andere Möglichkeit wäre sich einen PC MB Master zuzulegen und dann einfach alles ohne weitere Programmierung über USB auf RS485 mit dem PC MB User Interface konfigurieren. Das ginge höchstwahrscheinlich am Schnellsten.
David schrieb: > Die Verdrahtung ist schon komplett auf diesem "proxy" vorhanden Nutze keine Begriffe, die Du nicht verstehst. Das ist kein "Proxy", das ist ein simpler Treiber, so wie es aussieht, mit einer irgendwie hingepfuschten Sender-/Empfänger-Umschaltung. David schrieb: > Warum sollte ich aber noch auf Empfangsbetrieb umschalten, wenn ich dem > WS vertraue, dass er die Daten korrekt empfangen und umgesetzt hat (sehe > ich dann auch auf dem WS Display). Oder setzt der Slave beim MODBUS den > Empfang /Befehl nicht um, wenn der Master (PIC) die Rückantwort nicht > irgendwie nochmal empfängt ? Oh. Auf so eine Idee muss man erst mal kommen. Klar, Du kannst dem Ding auch einfach nur Daten senden, ohne jede Fehlerauswertung, ohne zu erkennen, ob die Daten auch angekommen sind ... aber das ist ja nun wirklich unter der Latte durchgesprungen und unnötig blind.
Harald K. schrieb: > aber das ist ja nun wirklich unter der Latte durchgesprungen und unnötig > blind. Es handelt sich im Ganzen um eine Regelung. Der Pic bekommt die Info, Leistung zu hoch bzw. niedrig und sendet über Modbus den entsprechenden vordefinierten Befehl. Würde dieser nicht ausgeführt vom WS, so würde sich die Regelgrösse nicht ändern und ein Fehler würde darüber erkannt werden...
:
Bearbeitet durch User
Die PICs wurden auch weiterntwickelt. Heute haben die Dinger in der Bezeichnung 5 Stellen nach dem F. Beispiel PIC16F18857 als 28-pinner, bei Reichelt für 2.70€ https://www.microchip.com/en-us/product/pic16f18857#document-table 4kbyte RAM und 56kbyte Programmspeicher. Dafür braucht man noch keinen PIC18. Gruß
David schrieb: > Es handelt sich im Ganzen um eine Regelung. Kann man natürlich so machen, ist halt Pfusch. Aber: So definitiv auch mit 'nem simplen kleinen PIC umsetzbar, insofern -- nur zu, viel Erfolg damit.
David schrieb: > Harald K. schrieb: >> aber das ist ja nun wirklich unter der Latte durchgesprungen und unnötig >> blind. > > Es handelt sich im Ganzen um eine Regelung. Der Pic bekommt die Info, > Leistung zu hoch bzw. niedrig und sendet über Modbus den entsprechenden > vordefinierten Befehl. Würde dieser nicht ausgeführt vom WS, so würde > sich die Regelgrösse nicht ändern und ein Fehler würde darüber erkannt > werden... Hatte ich auch mal vor, so ich beim Überfliegen alles richtig gelesen hab mit einem kleinen Wechselrichter den Nachtbedarf über Akkus decken… und Tagsüber wieder aufladen… War soweit, dass ich mit einem MEGA2560 die momentane Leistung -oder + am Einspeisepunkt ausgelesen hab. Mit dem DUE kannst über einen DAC Ausgang einem Step down eine Stromvorgabe machen, da die WR ja nach MPPT arbeiten War zu unwirtschaftlich mit dem Akku
Rahul D. schrieb: > PICs (16F84 oder so) habe ich damals diverse mit dem LudiPipo verflasht, > die nicht wiederbelebar waren Das ist auch nur ein Pfusch-Programmer - da wunderst Du Dich...? Gruss Chregu
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.