Habe bisher AVR-Studio 4.18 Win und Ponyprog verwendet. Viele Projekte realisiert. Will nun mit C beginnen, habe das Dr. Spanner Buch. Wie die Entwicklungsumgebung Win aussieht weiss ich, zuerst WinAVR installieren und dann das Studio. Aber jetzt lese ich, dass WinAVR outdated ist. Wie geht das also jetzt? bitte Hilfe. Am liebsten würde ich alles in Ubuntu machen, aber hat das AVR-Studio dann ein GUI? Und muss ich dann avrdude verwenden ? Ein paar Zeilen wären nett. LG Rudi
Hi, beim AVR Studio 5 ist der C-Compiler mit drin. Ich programmiere aber auch noch mit WinAVR und AVR Studio 4. Bisher keinerlei Probleme. Grüße Joe
Rudi D. schrieb: > Aber jetzt lese ich, dass WinAVR outdated ist. Die letzte verfügbare Version ist zumindest nicht gerade taufrisch. ;-) Trotzdem funktioniert sie natürlich noch, sie hat ja kein eingebautes Verfallsdatum. Eric wollte immer mal einen Nachfolger rausbringen, aber bislang ist das noch nicht passiert. > Wie geht das also jetzt? Atmel hat mittlerweile eine eigene Toolchain herausgegeben, das ist WinAVR minus AVRDUDE minus AVaRICE minus AVR-GDB. Ich weiß nicht, ob man inzwischen eine aktualisierte bekommt, die, die es zusammen mit AVR Studio 5 gab, war wohl recht buggy (teils selbst verschuldet, teils haben sie halt Pech mit einer buggigen Version der avr-libc gehabt). > Am liebsten würde ich alles in Ubuntu machen, Tu doch. > aber hat das AVR-Studio > dann ein GUI? AVR Studio kannst du dann vergessen; Atmel setzt ausschließlich auf Windows. Die 4er Version war wohl noch irgendwie unter Wine zum Laufen zu bekommen (wenngleich man mit dem Import der notwendigen Bibliotheken aus einem echten Windows vermutlich die Windows-Lizenz verletzen musste), aber AVR Studio 5 kannst du in dieser Hinsicht komplett vergessen. > Und muss ich dann avrdude verwenden ? Ja, und? Es gibt natürlich auch noch IDEs jenseits von AVR Studio, und die laufen dann durchaus auch auf deinem Ubuntu. Die berühmteste ist dabei wohl Eclipse, für das es ein AVR-Plugin gibt, aber es gibt natürlich viel mehr, angefangen bei Vim oder Emacs, die ja im 3. Jahrtausend eigentlich auch alles beinhalten was man braucht, um das Ganze dann IDE nennen zu können. Schwächster Punkt der Opensource-Tools ist wohl nach wie vor die Simulation. Andererseits: reale Applikationen kann man (aufgrund ihrer Außenbeziehungen) ohnehin nur zu einem Bruchteil simulieren, und für reine Algorithmen wiederum ist es ziemlich egal, ob der Simulator nun gerade deinen aktuellen Controller unterstützt oder nur einen älteren.
Rudi D. schrieb: > Aber jetzt lese ich, dass WinAVR outdated ist. > Wie geht das also jetzt? bitte Hilfe. "Outdated" heißt ja nicht, daß man es nicht mehr downloaden / benutzen kann. Lediglich weiterentwickelt wird es nicht. Entweder Du nimmst die WinAVR Toolchain und das AVR Studio 4.18 oder das neue AVR Studio 5.x, 6.x. Die Versionen ab 5 haben die C-Toolchain schon selber mit dabei. Sind mit dieser Visual Studio Shell aber ganz schon ressourcenhungrig. > Am liebsten würde ich alles in Ubuntu machen, aber hat das AVR-Studio > dann ein GUI? AVR-Studio und Ubuntu? Die AVR GCC-Toolchain hat per se keine GUI. Das läuft alles über make und das makefile. Kannst mit Eclipse arbeiten, wenn Du willst. WinAVR nutzt Programmer's Notepad als Editor. Da sind die passenden make-Aufrufe als Tools eingebettet und der Output auch umgelenkt. Fühlt sich für mich an wie eine GUI. Allerings ist makefile-Editieren angesagt - was ich aber praktischer finde als die verschachtelten Projekteinstellungen. > Und muss ich dann avrdude verwenden ? Nein, Du kannst, mußt aber nicht. Kannst die erzeugte HEX-Datei wie gehabt mit Ponyprog flashen. Wobei avrdude auch kein Hexenwerk ist und in den Standard makefiles, die bei WinAVR dabei sind, schon schön eingebunden sind. Dann reicht ein make all, make program und alles ist erledigt. Servus Michael
Ich danke Euch Allen, muss mich noch durchlesen. Eine GUI ist halt angenehm. Angst vor der Commandline habe ich nicht, aber die avrdude optionen sind sehr umfangreich, wie ich sehe. Werde sicher nochmals fragen müssen. LG Rudi
Rudi D. schrieb: > Eine GUI ist halt angenehm. > > Angst vor der Commandline habe ich nicht, aber ... Nene, schon klar ;) Jörg Wunsch schrieb: > Am liebsten würde ich alles in Ubuntu machen, > > Tu doch. Wie würde das dann aussehen? gcc + avrdude?
Rudi D. schrieb: > Werde sicher nochmals fragen müssen. Habe jetzt AVR-Studio 4.19 und WinAVR-20100110-install.exe geholt. Da war auch noch avr-toolchain-installer-3.3.0.710-win32.win32.x86.exe zum Download angeboten, was ich auch annahm. Ersetzt diese Toolchain irgendwie WinAVR, da es ja eine .exe, also für Win vorgesehen ist? AVR-Studio 5 möchte ich nur ungern installieren, da viel über den riesigen Umfang der Installation berichtet wird und ich nur kleine Projekte mache. LG Rudi
Kan asta schrieb: > Wie würde das dann aussehen? gcc + avrdude? AVRDUDE ist ja erst der letzte Schritt. Typischerweise macht man das über ein Makefile. Vielleicht willst du dir ja doch mal Eclips + AVR-Plugin ansehen?
Jörg Wunsch schrieb: > Vielleicht willst > du dir ja doch mal Eclips + AVR-Plugin ansehen? Nein danke, ich stehe nicht so auf Eclipse. Jörg Wunsch schrieb: > Typischerweise macht man das über ein Makefile ja mache ich auch so. Gut zu wissen, dass meine alten Projekte auch unter Linux kompiliert und geflasht werden können ;)
Jörg Wunsch schrieb: > Kan asta schrieb: >> Wie würde das dann aussehen? gcc + avrdude? > > AVRDUDE ist ja erst der letzte Schritt. > > Typischerweise macht man das über ein Makefile. Vielleicht willst > du dir ja doch mal Eclips + AVR-Plugin ansehen? Das verstehe ich nicht. Wenn ich unter Ubuntu Eclipse und passende Plugins installiere, dann hab ich doch nach der Kompilierung eines Projektes innerhalb Eclipse, wie ich annehme, schon ein HEX-file, das ich dann direkt mit averdude laden kann, oder? Irgendwie sind jetzt 2 Threads daraus geworden. Oberhalb steht noch meine Frage zur Toolchain. LG Rudi
Rudi D. schrieb: > Wenn ich unter Ubuntu Eclipse und passende > Plugins installiere, dann hab ich doch nach der Kompilierung eines > Projektes innerhalb Eclipse, wie ich annehme, schon ein HEX-file, das > ich dann direkt mit averdude laden kann, oder? Ja, wobei dir meiner Meinung nach das Plugin auch gleich die Möglichkeit bietet, das AVRDUDE aufzurufen. (Ich benutze selbst kein Eclipse, aber ich verfolge immer ein bisschen mit, was Thomas Holland da so gezaubert hat.) > Irgendwie sind jetzt 2 Threads daraus geworden. Ja, weil du halt zwei grundlegende Fragen hattest. ;-) Aber die zu WinAVR sind ja eigentlich auch beantwortet worden.
Jörg Wunsch schrieb: > WinAVR sind ja eigentlich auch beantwortet worden. Bis auf die Frage nach der avr-toolchain-installer-3.3.0.710-win32.win32.x86.exe
Rudi D. schrieb: > Bis auf die Frage nach der > avr-toolchain-installer-3.3.0.710-win32.win32.x86.exe Naja, ein "Ersatz" für WinAVR kann sie nicht sein, denn (wie ich schon einleitend schrieb) sie enthält nicht alles, was in WinAVR drin war. Sie enthält halt die Tools, die Atmel selbst als Ergänzung zum AVR Studio für essenziell erachtet.
na ja, ich weiss noch nicht was die Toolchain alles enthält, aber wenn man damit C-Programme für AVR_µC'S schreiben kann, dann sollte es ja für meinen Zweck reichen. Auch habe ich noch nicht gefunden, wie man die Toolchain im AVR-Studio incorporiert. Aber wird wohl bei AVR zu finden sein. Der folgende Eintrag ist ja von Ihnen. avr-libc-1.7.1 released eingetragen von joerg_wunsch, Mo 21 Feb 2011 10:42:00 UTC Der Unterschied zwischen der Toolchain und WinAVR würde mich noch interessieren. Wenn die Toolchain Bestandteil von WinAVR ist, dann habe ich keine Frage mehr. LG Rudi
> Habe bisher AVR-Studio 4.18 Win und Ponyprog verwendet. Viele Projekte > realisiert. > Will nun mit C beginnen, habe das Dr. Spanner Buch. > Wie die Entwicklungsumgebung Win aussieht weiss ich, zuerst WinAVR > installieren und dann das Studio. > Aber jetzt lese ich, dass WinAVR outdated ist. > Wie geht das also jetzt? bitte Hilfe. Wenn du keinen ultraneuen AVR-Typ verwendest, spielt das keine Rolle. Installationsanleitung im AVR-GCC-Tutorial. Ansonsten kannst du statt WinAVR auch AVR-Studio 5 mit der ATmel Version von avr-gcc benutzen, der Atmel Toolchain. Downloadlinks im Artikel AVR-Studio. Installationsanleitung als Filmchen bei Atmel. > Am liebsten würde ich alles in Ubuntu machen, aber hat das AVR-Studio > dann ein GUI? Warum zwei gravierende Sachen auf einmal ändern? AVR Studio ist ein Windows Programm und unter Ubuntu läuft das nur mit dem Zusatzpaket Wine. > Und muss ich dann avrdude verwenden ? Die aus dem C Quelltext kompilierte HEX Datei kannst du genauso wie die HEX-Datei aus dem Assembler mit Ponyprog flashen. Du kannst auch AVRDUDE verwenden. Die Bedienung ist keine Raketenwissenschaft. > Der Unterschied zwischen der Toolchain und WinAVR würde mich noch > interessieren. WinAVR ist eine Windows-Fassung von avr-gcc, die von Freiwilligen hergestellt wurde und auf Sourceforge.net zum Download bereitgestellt wird. Die letzte Fassung ist von Anfang 2010. Die Atmel Toolchain ist eine Windows-Fassung von avr-gcc, die von Atmel Angestellten ab 2010 hergestellt wird und auf einer Firmenseite von Atmel zum Download bereitgestellt wird. Der hauptbeteiligte Freiwillige im WinAVR Projekt ist mit dem hauptbeteiligten Atmel Angestellten bei der Atmel Toolchain identisch. Eine Aktualisierung von WinAVR ist vom hauptbeteiligten Freiwilligen und hauptbeteiligten Atmel Angestellten in Aussicht gestellt worden. Alles klar?
Krapao schrieb: > Der hauptbeteiligte Freiwillige im WinAVR Projekt ist mit dem > hauptbeteiligten Atmel Angestellten bei der Atmel Toolchain identisch. Das stimmt so nicht.
Krapao schrieb: > Eine Aktualisierung von WinAVR ist vom hauptbeteiligten Freiwilligen und > hauptbeteiligten Atmel Angestellten in Aussicht gestellt worden. Gemeint ist die Ankündigung in [1]. Andererseits schrieb selbiger Autor in [2]: >> 10.3 Future >> ~~~~~~~~~~~~ >> >> For all intents and purposes, this is the last release of WinAVR. >> The underlying tools contained in the WinAVR distribution will, >> of course, continue to be developed. >> >> For future toolchain distributions for Windows and other >> operating systems please refer to Atmel Corporation. In Anbetracht der schieren Menge an Tools, die WinAVR enthält sowie an Patches, die bekannte Fehler beheben, ist der Aufwand für so eine Distribution kaum zu überschätzen. Möchte man als Linuxer eine äquivalente Toolchain einsetzen, ist man viel weniger von einer vorgekauten Distribution wie WinAVR abhängig, denn Linux ist die "natürliche" Build-Umgebung für die Tools. Konkret: Es ist relativ einfach, sich eine Toolchain selbst zu generieren. Weil GCC und binutils Freie Software sind und Distributionen wie Atmel-Tools oder WinAVR darauf aufsetzen, müssen auch Patches, welche in die jeweilige Distribution eingeflossen sind, zur Verfügung gestellt werden. Diese Patches kann man natürlich auch unter Linux verwenden. Und zudem kursieren überall Build-Skripte, die dem Anwender das Erzeugen der Toolchain vereinfachen sollen -- ob sie es wirklich tun kann ich nicht sagen. Allerdings sind die Patches keine Garantie, daß alle (bekannten) Fehler behoben sind; so hat die Atmel-Toolchain mehrer Bugs nicht korrigiert, die im FSF-Repository bereits behoben sind und zu denen Lösungen angegeben sind. Alte Bekannte sind http://gcc.gnu.org/PR46779 http://gcc.gnu.org/PR39633 aber es werden auch neue Bugs eingebaut, siehe http://gcc.gnu.org/PR52474 Das betrifft zwar eine Debian-Distribution, verwendet aber Patches, die auch in der Atmel-Distro enthalten sind. > Du kannst auch AVRDUDE verwenden. > Die Bedienung ist keine Raketenwissenschaft. >> "Come on, Rory! It isn't rocket science, >> it's just quantum physics! -- The Doctor (Matt Smith)" Für die Einarbeitung in die neue Umgebung würd ich auch Zeit einplanen; zB bedienung von avrdude, neuem Editor bzw. IDE/GUI. Direkt loslegen bringt da oftmals Frust; Doku lesen ist keine Zeitverschwendung und schont Nerven. Auf einen Simulator/Debugger würd ich ganz verzichten; zumindest ist meine Erfahrung daß sie für AVR-Entwicklung eher nutzlos sind. Einmal angetestet mit AVR-Studio (und nach dem geschreiterten Versuch den Riesenmoloch gleich wieder vom Bord gekippt): In vivo ist ds eh nicht testbar, da die Rückkopplung mit der Einsatzumgebung fehlt. Sporadische Fehler wie nicht-atomare Zugriffe oder fehlgeleitete Pointer etc. findet man damit auch nur schwerlichst. Und Sprache wie C durch Trial-and-Error zu lernen nach dem Motto "Irgendwas eintippen und gucken was der µC so macht", davon würd ich abraten. Lernen per Reverse-Engineering sollte man sich erst garnicht angewöhnen wenn es bessere Wege gibt. Debugger/Simulator sind keine Design-Tools und ersetzen keine fundierten (Sprach-)Kenntnisse. Nicht-invasives Debugging, also ohne Codeänderung und ohne das Timing zu beeinflussen, geht damit eh nicht. Wie hab ich das Problem damals gelöst? 1/4 Stunde Pause gemacht, Tastatur beiseite gelegt und nachgedacht. Nach 5 Minuten hatte ich den Fehler; in den Code geschaut, korrigiert und fertig. Und dann, wie gesagt, diesen Studio-4 Klotz entsorgt. Unter Windows verwende ich Programmer's Notepad oder Textpad; unter Linux Emacs. Emacs ist einfach unübertroffen. (Aber leider auch unübertroffen kompliziert darin, ihn so zu konfigurieren, wie man ihn gerne hätte). -- [1] http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=107269&start=all [2] WinAVR-20100110!/WinAVR-user-manual.txt
Naja, die Aussage in [2] ist um einiges vor der in [1] entstanden, insofern ist es nicht verwunderlich, dass sie sich widersprechen. Bezüglich Debugging: nicht immer geht das mit Zurücklehnen und Nachdenken. Ein Simulator war mir beispielsweise bei den ersten printf-Implementierungen (vor allem für Gleitkomma) eine große Hilfe, denn da kommt es nicht auf Zeitverhalten oder äußere Einflüsse an, sondern rein auf die Algorithmen. Allerdings ist es dabei eben ziemlich egal, ob man einen ATmega16 oder einen ATmega1281 simulieren lässt, der Algorithmus bleibt ja in beiden Fällen gleich. Dass ein Emulator eine nützliche Hilfe (besonders in großen Projekten) sein kann, haben wir hier ja gerade als Fazit gehabt: Beitrag "Stabilstes Debugging für AVRs"
Jörg Wunsch schrieb: > Naja, die Aussage in [2] ist um einiges vor der in [1] entstanden, > insofern ist es nicht verwunderlich, dass sie sich widersprechen. Ja, ich weiß. Ist Dir denn näheres bekannt? [1] ist nun auch schon run 10 Monate her, und ausser Spekulationen und Mutmaßungen gibt's nichts ad [1]. [2] geht wohl auf Erics Anstellung bei Atmel zurück, und daß sie sich nicht selber Konkurrenz machen wollen sowie darauf, nur das zu unterstützen, was AStudio braucht und nicht etwa "Open-Source- und Linux-Frickelsoftware, die eh kein Mensch braucht" ...wenn ich mal etwas überspitzt formuliere, was ich als Grund für den "Demise of WinAVR" vermute. > Bezüglich Debugging: nicht immer geht das mit Zurücklehnen und > Nachdenken. Ein Simulator war mir beispielsweise bei den ersten > printf-Implementierungen (vor allem für Gleitkomma) eine große Hilfe, > denn da kommt es nicht auf Zeitverhalten oder äußere Einflüsse an, > sondern rein auf die Algorithmen. Allerdings ist es dabei eben > ziemlich egal, ob man einen ATmega16 oder einen ATmega1281 simulieren > lässt, der Algorithmus bleibt ja in beiden Fällen gleich. Ja, mit Maß und Ziel eingesetzt sind das natürlich hilfreiche Tools. Zum Auffinden von Compilerfehlern wie [3] verwende ich u.U. auch einen Simulator, den avrtest. Aber gerade der dürfte unter allen AVR-Simulatoren derjenige sein, der für die breite Masse am wenigsten interessant ist. Meine Anmerkung oben bezog sich auf die inflationäre Verwendung von "Simulator als Design-Tool oder Sprachreferenz". Nach dem Motto: F: Was macht dieses C-Konstrukt? A: Schau an, was der Simulator macht! -- [3] http://gcc.gnu.org/viewcvs/trunk/gcc/config/avr/avr.c?r1=184559&r2=184558&pathrev=184559
Johann L. schrieb: > Ist Dir denn näheres bekannt? Ja, wenngleich ich auch nicht alles öffentlich diskutieren mag. > [2] geht wohl auf Erics Anstellung bei Atmel zurück Nö, Eric ist seit (ich glaube) 2006 bei Atmel. Er hat also WinAVR über viele Jahre als Atmel-Angestellter gebaut. > um > Auffinden von Compilerfehlern wie [3] verwende ich u.U. auch einen > Simulator, den avrtest. Aber gerade der dürfte unter allen > AVR-Simulatoren derjenige sein, der für die breite Masse am wenigsten > interessant ist. Sein Entwicklungszweck war/ist es ja auch, für den Compiler als möglichst schneller Simulator für den reinen Core, ohne jegliche Peripherie, zur Verfügung zu stehen. Andere Simulatoren versuchen zumindest noch, ein wenig Peripherie zu simulieren (nicht alle Peripherie braucht zwingend eine Außenanbindung, bspw. Timer nicht).
Jörg Wunsch schrieb: > Johann L. schrieb: >> zum Auffinden von Compilerfehlern wie [3] verwende ich u.U. auch >> einen Simulator, den avrtest. Aber gerade der dürfte unter allen >> AVR-Simulatoren derjenige sein, der für die breite Masse am wenigsten >> interessant ist. > > Sein Entwicklungszweck war/ist es ja auch, für den Compiler als > möglichst schneller Simulator für den reinen Core, ohne jegliche > Peripherie, zur Verfügung zu stehen. Andere Simulatoren versuchen > zumindest noch, ein wenig Peripherie zu simulieren (nicht alle > Peripherie braucht zwingend eine Außenanbindung, bspw. Timer nicht). Jo, Peripherie-Simulation im avrtest wäre dabei sinnfrei, denn kein einziger Testfall enthält Peripherie-Code. Achillesferse im avr-gcc ist eher ISR-Code; da waren schon einige Klopper drinne. Wirklich ne Idee wie man ISR-Code testen kann hab ich aber auch net. Ne Timer-Mimik braucht's dazu mal nicht, und eine solche will man auch garnicht. Es würde ausreichen, per Option ne ISR-Rate zu setzen und in exit-target.o ISRs zu implementieren und in vorgegebenem, reproduzierbarem Timing auszuführen. Aber das würde zum einen die Suite ausbremsen und zum anderen immer den gleichen ISR-Code verwenden. Die ISR-Mimik selber ist nicht viel; Xmega war auch schnell reingeklöppelt in avrtest, zum Glück ist der frei und schön simpel gestrickt.
Krapao schrieb: > Die Atmel Toolchain ist eine Windows-Fassung von avr-gcc, die von Atmel > Angestellten ab 2010 hergestellt wird und auf einer Firmenseite von > Alles klar? Dann werde ich zunächst einmal auf XP bleiben mit WinAAR in AVR-Studio 4.19. Wine benütze ich nicht. CrossOver schon (das Officepaket läuft gut unter Ubuntu, war ich von früher gewohnt). Nachdem ich zum Arbeiten mit s.o. keinen Netzzugang brauche, macht die geringere Sicherheit von XP gegenüber Linux nichts aus. Später möchte ich schon alles unter Linux, aber bequem mit GUI laufen haben. Zu Atmel: Nachdem im Studio 5 die Toolchain integriert ist, find ich dort offenbar nicht mehr, wie man die Toolchain in Studio 4 integrieren kann, ist aber s.o. nur von akademischem Wert. Ich danke Allen für die ausführliche Hilfe und Information. Meine Projekte sind ja nur Hobby in der Pension, einiges hier: http://elektronik-labor.de/AVR/LCmeter.html
Noch eine sehr schöne und preiswerte IDE zum AVR-GCCist AtmanAVR, sicher auch sehr gut für Einsteiger geeignet! http://www.atmanecl.net/atmanavr/default.htm
Peter S. schrieb: > Noch eine sehr schöne und preiswerte IDE zum AVR-GCCist AtmanAVR, sicher > auch sehr gut für Einsteiger geeignet! > > http://www.atmanecl.net/atmanavr/default.htm Danke für die Info, ist aber für Win, da habe ich ja das AVR-Studio schon bisher für Assembler verwendet. Aber jetzt kommt's: Habe also gestern WinAVR und Studio 4.19 und in dieser Reihenfolge installiert. Nebensatz: auf einem anderen Comp habe ich WinAVR und Studio4.16 installiert und es läuft auch für C alles ok. Beispiele laufen ohne Fehlermeldung ab. Mit Studio 4.19 geht das nicht gut. Als erstes beim einschalten: gcc: no plugin found, aber sie können es mit .... nicht gemerkt lösen Auch ein Buildvorgang erfolgt mit Fehlern, fehlermeldung leider nicht gemerkt. Also mit AVR-Studio5 versucht. Zuerst der volle Download mit 600MB. Bei der Installation fehlt dann allerhand, Install bricht ab. Also den kleinen Download geholt mit 400 MB, der sich den Rest aus dem Netz holt. Dann installiert es ziemlich lang um am Ende wieder abzubrechen mit XP-SP3 ist nötig. Habe nur SP2. Also ACHTUNG darauf wenn wer Studio5 haben will. Da waren schon viele Stunden hin und ich sauer. Heute habe ich dann WinAVR und Studio 4.18 installiert, das ich noch hatte. Alles läuft o.k. wie auf dem anderen Comp. mit Studio 4.16. Ich habe gerne Ausweichmöglichkeiten, da ja Comp. ausfallen können. Ich bin natürlich kein Spezialist und kenne mich in den Tiefen von WinAVR, Toolchains u.a. nicht aus, will nur das was als Beispiel funktioniert auch bei mir zum Project-Build ohne Fehlermeldung bringen. Na geschafft hab ich es ja, aber in meinem Fall hat es wohl was mit AVR-Studio 4.19 zu tun, vor dem ich C-Anfänger nur warnen kann. Um zu lernen gehe ich gerne von bestehenden Projekten aus, die ich dann durcharbeite und lerne, ehe ich etwas Neues, aufbauend auf Bekanntem realisiere. Ich werde ein U-Wert Messgerät entwickeln, das ja mit Messung von 3 Temperaturen diesen Wert errechnen kann. Energiesparen ist ja nicht unwichtig.
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.