Hallo, ich spiele gerade mit dem Gedanken, aus der AVR-Welt kommend die Nase mal in ARM zu stecken. Bei der Suche nach einer IDE stoße ich auf CooCox und CoIDE, und im Wiki steht dazu auf der LPC1xxx Seite: "einem chinesischen Open-Source Projekt". Hmmmm - das Chinesische daran ist wohl, dass es geklaut und keineswegs Open Source ist? Jedenfalls kann ich keinen Quelltext finden, und im CooCox Forum beschweren sich einige Anwender darüber, dass alles nur binär für Windows zur Verfügung steht. Übersehe ich da etwas? Oder ist dies tatsächlich nur ein parasitäres Projekt? Dann käme es für mich nicht in Frage.
:
Verschoben durch Moderator
Was genau wird als Open Source aufgeführt? Auf der Homepage bezieht sich dieser Begriff auf Libraries, Treiber und RTOS. Nicht auf die Entwicklungsumgebung jenseits des Compilers. Dass es sich beim Compiler um GCC handelt ist völlig legitim. Andere verwenden aber auch GCC als Grundlage. Und nicht immer so, wie GNU sich das gedacht hat. Microchip tut das in etwas grenzwertiger Form, die an Methoden von Rechtsverdrehern erinnert. Deren 16- und 32-Bit Umgebungen basieren auf GCC, dem sie zusätzliche Optimierungen beigebracht haben, ohne diese als Quellcode zu veröffentlichen. Das haben sie dadurch legal erreicht, indem sie den Compiler zwischendurch quasi aufbrechen, die Optimierungen mit einem separaten Programm auf dem Zwischencode durchführen, um dann mit dem Rest vom GCC darauf basierend wieder weiter zu machen. Soviel zu "Chinesen im Geiste".
:
Bearbeitet durch User
AVR-Bastler schrieb im Beitrag #4428960: > Oder ist dies tatsächlich nur ein parasitäres Projekt? Hallo: Was ist ein "parasitäres Projekt" ? Gruß Marc
AVR-Bastler schrieb im Beitrag #4428960: > Oder ist dies tatsächlich nur ein parasitäres Projekt? Hallo: Was ist ein "parasitäres Projekt" ? Gruß Marc AVR-Bastler schrieb im Beitrag #4428960: > ich spiele gerade mit dem Gedanken, aus der AVR-Welt kommend die Nase > mal in ARM zu stecken. Zum Nase reinstecken kannst du doch auch die Demoversionen der "professsionellen System" nehmen. Wenn du mit "freeware --> Malware,...." Probleme hast ;-)
A. K. schrieb: > Auf der Homepage bezieht sich > dieser Begriff auf Libraries, Treiber und RTOS. Nicht auf die > Entwicklungsumgebung jenseits des Compilers Wenn ich das richtig sehe, wird ein verändertes Eclipse verwendet, dessen Quelltext nicht veröffentlicht wird.
AVR-Bastler schrieb im Beitrag #4429036: > Wenn ich das richtig sehe, wird ein verändertes Eclipse verwendet, > dessen Quelltext nicht veröffentlicht wird. Das stünde wohl im Widerspruch zur Lizenz von Eclipse (EPL): "A Contributor may choose to distribute the Program in object code form under its own license agreement, provided that: [...] iv) states that source code for the Program is available from such Contributor, and informs licensees how to obtain it in a reasonable manner on or through a medium customarily used for software exchange."
Marc schrieb: > Wenn du mit "freeware --> Malware,...." Probleme hast ;-) Nein, ich habe mit Freeware keine Probleme. Aber Freeware und Open Source sind zwei völlig verschiedene Paar Schuhe. Natürlich gibt es Menschen, die alles, was sie im Leben interessiert (Mikrocontroller, Auto, Haus, Frau, Kinder), nur nach dem Preis in Euro bewerten - für diese Leute gibt's da natürlich keinen Unterschied, da beides kostenlos ist. > Was ist ein "parasitäres Projekt" ? Open-Source beruht auf Geben + Nehmen. Parasiten sind solche, die gegen den Willen des Wirts nehmen und nichts zurück geben (außer Antikoagulanzien, Boreliose, usw.)
A. K. schrieb: > Das stünde wohl im Widerspruch zur Lizenz von Eclipse (EPL Ja, genau das ist der Kritikpunkt im CooCox Forum. Da CooCox sagt, dass sie keine Linux-Version planen, gab es offenbar Interesse, einen Port zu machen - aber CooCox schweigt auf Fragen zum Quelltext.
Dreh doch einfach den Kopf um 90Grad. Da kommt aus einer anderen Richtung bestimmt eine gebratene Taube angeflogen die dir besser schmeckt...
Jojo S. schrieb: > Für die LPC1xxx ist das LPCXpresso von NXP auch sehr gut zu > gebrauchen. Danke! Ich habe mal reingeschaut: Quelltext der offenen Komponenten ist dabei, läuft unter Linux. Nachteil: Sobald man mal einen Chip von STM verwenden will, muss man wohl die IDE wechseln. Wieso eigentlich? Ich denke, die ARM sind alle gleich?
AVR-Bastler schrieb im Beitrag #4428960: > ich spiele gerade mit dem Gedanken, aus der AVR-Welt kommend die Nase > mal in ARM zu stecken. > > Bei der Suche nach einer IDE stoße ich auf Hä? Was willst du eigentlich? Du behauptest, "die Nase mal in ARM zu stecken" und als allererstes fängst du an, mit der Suche nach irgend einer IDE. Das hat mit "Nase in ARM" so viel zu tun wie die Kuh mit dem Fliegen. Anschließend kommt hier eine Diskussion auf über Opensource/Freeware/Befindlichkeiten und so. Das hat mit dem "Nase in Arm" noch viel weniger zu tun. Also, wenn du es tatsäüchlich ernst meinst und hier nicht bloß herumtrollen willst, dann lade dir die Dokus zu den diversen aktuellen Arm-Architekturen von arm.com herunter und fange dann an mit Lesen - damit du verstehst, wohinein du deine Nase stecken willst. Aktuell sind so etwa Cortex M0, M0+, M3 und M4 bzw. M4F - ja es gibt noch viel mehr, aber die Genannten sind so etwa das, was für dich am ehesten in Frage kommt. Am ehesten würde ich dir zu einem Cortex M4F raten, denn der hat sowohl DSP als auch Gleitkomma intus und kostet auch nicht viel mehr als die anderen genannten. Als nächstes würde ich dir zur Demoversion vom "Keil" raten. Solange du keine Riesenprojekte angehst, reicht die dir erstmal aus und du hast nen professionellen Compiler zur Verfügung. Einen normalen Editor wirst du ja wohl besitzen, also brauchst du nur noch eine simple Batchdatei zum Kompilieren und fertig ist die Soße. Jede (wirklich JEDE) IDE macht im vergleich dazu nur einen Haufen Schaumschlägerei, was dich von deinem eigentlichen Ziel ablenkt. Zum Schluß guck dir einen µC aus, der einen eingebauten Bootlader hat - irgend ein LPCxyz von NXP zum Beispiel. Mit so einem Teil kriegst du deine selbstgeschriebenen Ergüsse am einfachsten in den Chip. Jetzt werden gleich wieder einige schreiben, daß es ohne JTAG/SWD ja garnicht geht, weil sie ja nur dann etwas zuwege bringen können, wenn sie auch debuggen können - um herauszukriegen, was der Compiler aus ihrem Kauderwelsch gemacht hat. Die Alternative wäre ein Seggerscher J-Link aus China oder ein J-Link-Edu nebst geklauter Flash-Lizenz - aber ob du das willst, mußt du selber entscheiden. Wieder weden jetzt einige schreiben, daß man ja auch mit einem FTDI-Chip und OpenOCD sich befassen könnte - aber das ist ebenfalls mehr Gefummel im Abseits als daß es nützt zu "Nase in ARM". W.S.
AVR-Bastler schrieb im Beitrag #4429317: > Ich denke, die ARM sind alle > gleich? Im Kern ja, aber die Peripherie ist unterschiedlich und vor allem wie der interne Flash programmiert wird. Den Compiler kann man schon für µCs anderer Hersteller nutzen, aber der Support beim Debuggen fehlt und der Komfort was z.B. Linkerfiles erstellen fehlt weil NXP nur die Daten seiner MCUs integriert hat.
AVR-Bastler schrieb im Beitrag #4429317: > Nachteil: Sobald man mal einen Chip von STM verwenden will, muss man > wohl die IDE wechseln. Wieso eigentlich? Naja, NXP "verschenkt" ja die IDE, zumindest in der freien Version, die IMHO bis 256 kB Code kann. Dass die jetzt da keinen Support für STM (für die Konkurrenz) einbauen, ist ja naheliegend. Der gcc kann aber natürlich erstmal Code für alle Cortexe generieren, eclipse kann die auch (mit den geeigneten Plugins) unterstützen.
AVR-Bastler schrieb: > ich spiele gerade mit dem Gedanken, aus der AVR-Welt kommend die Nase > mal in ARM zu stecken. Lektion Nr. 1: W.S. schrieb: > Was willst du eigentlich? Nicht auf das wirre Geschreibsel von W.S. hören, das er dir bei jedem Beitrag zu Cortex-M um die Ohren haut. Hier gibt es eine Auswahl an Entwicklungsumgebungen, keiner zwingt dich CooCox zu verwenden: https://www.mikrocontroller.net/articles/STM32#Freie_Software.2FFreeware Hier gibt es beispielsweise ein Tutorial für eclipse+GCC für sowohl Linux+Windows: STM32 Eclipse JLink Linux/Windows. Außer der JLink-Software ist daran alles Open-Source. Dafür hast du mit JLink auch den schnellsten Debugger auf dem Markt, unterstützt die deutsche Wirtschaft und hast 1A Linux Support ;-) Alternativ kannst du auch OpenOCD + ST-Link nehmen, dann ist es 100% Open Source. W.S. schrieb: > also brauchst du nur noch eine simple Batchdatei zum > Kompilieren und fertig ist die Soße. Jede (wirklich JEDE) IDE macht im > vergleich dazu nur einen Haufen Schaumschlägerei, was dich von deinem > eigentlichen Ziel ablenkt. Aber eigene Batchdateien machen und Libraries zusammen suchen lenkt nicht ab? Wenn du empfiehlst, Keil nur als Compiler zu benutzen, und die ganzen "Vorteile" nicht zu nutzen, kannst du auch gleich den GCC empfehlen, denn der ist Open Source, geht unter Linux, kann neueste Sprachstandards (C++11), und hat kein 32kB-Code-Limit. W.S. schrieb: > Jetzt > werden gleich wieder einige schreiben, daß es ohne JTAG/SWD ja garnicht > geht, weil sie ja nur dann etwas zuwege bringen können, wenn sie auch > debuggen können - um herauszukriegen, was der Compiler aus ihrem > Kauderwelsch gemacht hat. Richtig erkannt. Der W.S. ist ein Genie der Programmen (ggf im Assembler Code) alle Fehler ansehen kann, inklusive dem was die Peripherie so macht. Da 99% der Entwickler aber keinen Röntgenblick haben, ist es für diese enorm hilfreich einen echten Debugger zu haben. Dieser hilft - insbesondere wenn die Projekte mehr als 100 Zeilen haben - sehr dabei Fehler schneller(!) zu finden. Wenn man schon weg vom AVR will, kann man auch gleich die Vorteile vom ARM genießen, wie eben richtiges Debugging. W.S. schrieb: > Die Alternative wäre ein Seggerscher J-Link aus China Der dann bald nicht mehr funktioniert wenn die JLink-Software ein Firmware-Upgrade macht bzw. die geklaute Serien-Nr. erkennt W.S. schrieb: > oder ein > J-Link-Edu nebst geklauter Flash-Lizenz J-Flash brauchts nicht, denn im Hobby-Bereich will man wohl kaum Massen-Programmierung betreiben. Für einfaches Flashen reicht auch J-Flash Lite (gratis) oder einfach die JLink-Kommandozeile (auch gratis). Gerade W.S. sollte sich doch über Kommandozeile ohne Klicki-Bunti-freuen!
AVR-Bastler schrieb im Beitrag #4429317: > Nachteil: Sobald man mal einen Chip von STM verwenden will, muss man > wohl die IDE wechseln. Wieso eigentlich? Ich denke, die ARM sind alle > gleich? Zwar basieren die Microcontroller von Hersteller wie NXP, ST Microelectronics usw. meistens auf denselben ARM-Kernen, die diese Hersteller eben bei ARM eingekauft haben. Bezüglich der Ausgestaltung der Peripherieblöcke gibt es jedoch erhebliche Unterschiede. Bei den Cortex-basierten Prozessoren/Controllern gibt es zwar von ARM ein paar Vorgaben (CMSIS-"Standard"), aber die Bausteine sind eben nicht 1:1 austauschbar. Die Prozessorhersteller stellen heutzutage gerne ein paar IDEs oder Bibliotheken kostenlos bereit, um damit die Kunden an ihre Produkte zu binden. Liest man sich nämlich die Lizenzbedingungen durch, stellt man sehr schnell fest, dass dort sinngemäß steht: "Ihr könnt alles mit unseren Bibliotheken anstellen, solange sie nicht auf Produkten von Fremdherstellern eingesetzt werden". Solche Bedingungen sind auch sehr gut nachvollziehbar, denn schließlich hat der Hersteller (oder die von ihm beauftragte Softwarebude) auch viel Geld und Zeit hineingesteckt. Grenzwertig sind aber in der Tat Produkte, deren Open-Source-Herkunft verschleiert und/oder die Lizenzbestimmungen nicht eingehalten werden. Zuguterletzt muss man auch immer fragen, wer denn überhaupt gegen wen einen Anspruch auf Herausgabe der Quellen oder einen Unterlassungsanspruch besitzt. Es ist keineswegs so, dass jeder diese Ansprüche durchsetzen kann. Im Zweifelsfall können nur die Autoren der ursprünglichen Software irgendetwas durchsetzen. Wenn Organisationen wie z.B. gpl-violations.org gegen einen Rechtsverletzer vorgehen wollen, müssen sie immer mindestens einen Autor mit an Bord haben. Als Konkurrenzunternehmen hat man ggf. noch die Chance, auch ohne Beteiligung eines Autors vorzugehen, nämlich auf wettbewerbsrechtlichem Wege, wenn ein Anbieter die OS-Herkunft seiner Software nicht ordnungsgemäß (d.h. den jeweiligen Lizenzbedingungen entsprechend) kennzeichnet.
Dr. Sommer schrieb: > Dafür hast du mit JLink auch > den schnellsten Debugger auf dem Markt, unterstützt die deutsche > Wirtschaft und hast 1A Linux Support ;-) Kannst Du bitte eine seriöse Quelle nennen, die den JLink im Vergleich zu einem Lauterbach ICD getestet hat und zu solch einem pauschal gültigen Ergebnis gekommen ist? Ich meine damit nicht irgendeinen Hochglanzprospekt von Segger. Die anderen Merkmale (deutsches Produkt, erstklassiger Linux-Suppprt, und zwar sowohl für Linux-Hosts als auch -Targets) treffen nämlich auch auf Lauterbach zu. Nachtrag: Ich wollte ursprünglich noch scherzhaft gefragt haben, ob Lauterbach denn auch noch DEC VMS unterstützt. Ein Blick auf die Homepage ergibt, dass sie in der Tat noch VMS sowohl auf Alpha als auch VAX unterstützen... Das nenne ich 'mal Produktpflege! Wir haben eine mittlerweile knapp zehn Jahren alte Debugger-Hardware von Lauterbach, die aber auch heute noch für alle aktuellen Prozessoren unterstützt wird. Wir mussten nur zwischendurch einen neuen Stecker mit Pegelwandler kaufen, wodurch es möglich wäre, auch Prozessoren mit 0,7V Kernspannung zu debuggen.
:
Bearbeitet durch User
Wenn ich Auto fahren möchte fange ich auch nicht damit zu lernen wie der Motor konstruiert ist. Für einen Anwender ist für mich die Nutzung einer IDE nix Verwerfliches. Wenn man Erfahrungen mit anderen IDEs hat kommt man mit LPCXpresso oder Keil µVision gut zurecht. Bei LPCXpresso ist anfangs nur die Fülle an Optionen erschlagend, dafür sollte man das mitgelieferte User Guide durchsehen. Als JTAG Debugger kann ich den LPCLink-2 empfehlen, der kann JTAG und SWD. Per Firmware kann man den CMSIS-DAP oder J-Link kompatibel machen, damit verträgt der sich z.B. auch mit CooCox.
Hallo, Schau doch mal die STM32 Reihe und die Evalboards dazu an. Die Discoveryboards sind sehr günstig und haben schon einen integrierten Debugger mit dabei. Ich habe mich damals für STM32F4Discocery entschieden, da dieser massig Speicher, VIELE Timer (17 PWM Kanäle), DSP und eine FPU hat. Außerdem ist ein AudioDAC, sowie ein Beschleunigungssensor an Board. Riesen Vorteil ist eben, dass ein ST-Link V2 Debugger/Flasher an Board ist. http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF252419?sc=internet/evalboard/product/252419.jsp Als Toolchain würde ich GCC nehmen. Gründe: - Sehr aktuell (Kann C++11) - kostenlos/OpenSource - Viele andere professionelle IDEs nutzen auch den GCC - Viele Tutorials im Netz Falls du dich zusätzlich noch in ein RTOS einarbeiten möchstes dann schau dir unbedingt ChibiOS an. Das ist ein OpenSource RTOS besonders für die STM32 Reihe. ChibiStudio ist ein Paket aus Eclipse + GCC + Tools für eben ChibiOS und STM32. Einfach nur downloaden und loslegen. Du kannst statt der RTOS Demos auch einfach "Bare-Metal" programmieren und einfach nur die Toolchain nutzen. http://www.chibios.org/dokuwiki/doku.php?id=chibios:product:chibistudio:start
Andreas S. schrieb: > Kannst Du bitte eine seriöse Quelle nennen, die den JLink im Vergleich > zu einem Lauterbach ICD getestet hat und zu solch einem pauschal > gültigen Ergebnis gekommen ist? Leider nicht. Weißt du ob der Lauterbach schneller ist? Es scheint allgemein wenig Informationen zu dem im Netz zu geben. Wäre auch ein Argument dagegen... ;-) Scheint auch hier im Forum bzw. allgemein der Hobby-Community kaum vertreten zu sein. Aber um die Wahl des Debug-Adapters gings hier eigentlich gar nicht...
Versuchs doch mal mit "TrueStudio lite" wenn dein Chip unterstützt wird. Für den Einstieg reichts und anders als viele anderen Bastel-IDEs läuft es Out-Of-The-Box. Glaube es hat keine Code-Begrenzung, nur einige Debug-Features kosten extra $$$.
Dr. Sommer schrieb: > Aber eigene Batchdateien machen und Libraries zusammen suchen lenkt > nicht ab? Guck dir die Lernbetty an, da kannst du sehen wie man sowas macht - jaja auch du kannst daraus noch was lernen. Hast du eigentlich jemals was anderes gemacht als naseweises Zeug von dir gegeben? Du nervst bloß. Aber zurück zum Thema: Ich sehe durchaus, daß es ne Menge Leute gibt, die am liebsten in irgend einer IDE herumklicken wollen, wobei es ihnen eigentlich eher nebensächlich ist, worauf sich diese IDE bezieht. Und da es mittlerweile eben hipp geworden ist, von sich ganz laut sagen zu können "Hört mal alle her, ICH BEFASSE MICH MIT A_R_M", kommt eben das Nachfragen nach der hippesten IDE für Arm auf. Es ist ja jedem unbenommen, sich genau damit zu befassen, was ihm denn so in den Sinn kommt, zum Beispiel eben das Herumdaddeln in einer Verfinsterung (Eclipse) oder so. Aber aus böser Erfahrung weiß ich, daß die meisten, die so anfragen, sich später als Entwicklungsingenieure bewerben und in vollstem Stolz von sich behaupten, daß sie sich mit 32 Bit Controllern bestens auskennen - obwohl sie mal grad irgend ein HelloWorld mittels LPCxpresso oder dergleichen hingekriegt haben und von all dem, was sie eigentlich können sollten, keinen Schimmer haben. Und unsereiner muß dann binnen 6 Monaten - ach lassen wir das, dazulernen muß jeder, der in ne Firma kommt, aber man sollte besser von vornherein wissen, worauf man sich einläßt, sonst verplempert jeder nur seine Zeit. So also, jedem Tierchen sein Plaisierchen, deswegen meine begründete Frage, was der TO denn eigentlich will. W.S.
W.S. schrieb: > Guck dir die Lernbetty an, da kannst du sehen wie man sowas macht Hab ich doch schon, und dir doch schon erläutert was daran alles falsch ist. Ich erinnere mich an so grausame Dinge wie Makros für Typdefinitionen zu verwenden. W.S. schrieb: > jaja auch du kannst daraus noch was lernen. Ja, was für verrückte Leute es gibt. W.S. schrieb: > Du nervst bloß. Aber du nicht? Warum überhaupt batch files und keine makefiles? Ist doch viel zu langsam und nervig. Und es ist ja schön dass du alles auf der Konsole mit direktem Compileraufruf kompilieren kannst. Ja, das kann ich und viele andere auch. Das ist noch lange kein Grund sich deswegen besonders cool zu fühlen, und zu behaupten dass man mit einer IDE, die das automatisch macht, nicht viel schneller ist. W.S. schrieb: > Aber aus böser Erfahrung weiß ich, daß die meisten, die so anfragen Jaja blablabla alle sind doof außer mir, aber das hat nichts damit zu tun dass es zur Steigerung der Produktivität durchaus sinnvoll ist, IDE's und Debugger zu nutzen.
Jojo S. schrieb: > Wenn ich Auto fahren möchte fange ich auch nicht damit zu lernen wie der > Motor konstruiert ist. Für einen Anwender ist für mich die Nutzung einer > IDE nix Verwerfliches. Diese Art zu diskutieren ist sachlich falsch. Ich erläutere es dir mal: Wenn deine Tochter sich nen MP3-Player kauft, um damit ihre allerneuesten Songs zu hören, dann ist es ihr zu Recht völlig wurscht, ob darin ein Arm oder ein grünes Marsmännchen werkelt. Das Ding muß bloß die Songs ordentlich abspielen. Deine Tochter ist Anwender. Wenn du hingegen ein Entwicklungsingenieur sein willst, der "sich mit ARMs befaßt", dann mußt du dich zwangsweise mit den Innereien des Chips befassen, auch damit, was man damit machen kann und wo seine Grenzen liegen, wie tatsächlich was geht und so weiter. Du bist eben nicht Anwender wie deine Tochter mit ihrem MP3-Player. Deshalb ist deine Argumentation sachlich falsch. Ansonsten ist das Verwenden einer IDE durchaus nichts Verwerfliches, man ist ja kein Extremist, gelle? Aber mit dem Vorhaben zu starten "ich spiele gerade mit dem Gedanken, aus der AVR-Welt kommend die Nase mal in ARM zu stecken" und dann komplett an der Zielrichtung vorbeizurennen und sich auf irgend eine IDE stürzen zu wollen, ist ein schwerer Fehler am Anfang von Allem, auf den man so einen Beginner hinweisen muß, wenn man ihn nicht verscheißern will. W.S.
W.S. schrieb: > So also, jedem Tierchen sein Plaisierchen, deswegen meine begründete > Frage, was der TO denn eigentlich will. > > W.S. Ich denke außer Dir ist das wohl jedem klar. Dies hier könnte ein guter Startpunkt für einen STM32 Anfänger sein. http://www.carminenoviello.com/en/2014/12/28/setting-gcceclipse-toolchain-stm32nucleo-part-1/ Er hat auch ein Script womit sich per Cube erzeugte Projekte in Eclipse importieren lassen. Wenns nicht Eclipse sein soll fand ich EmBitz auch sehr nett, das einzige Problem dabei ist der Projektimport von Cube. Gruß Stephan
Wenn ich an einem Projekt arbeite nutze ich zu 99 % den Editor in der IDE, was hat das mit 'herumdaddeln' in einer IDE zu tun? Anfangs kommen die Projekteinstellungen wie MCU Auswahl, Suchpfade und Defines einstellen dazu. Und sich mit gcc Einstellungen in Makefiles herumplagen hat nichts mit ARM Programmierung zu tun. So ein STM32 Disco Board habe ich, ST verteilt die ja wie Kamelle zu Karneval. Für den Einbau in eigene, kleine Sachen waren mir die immer zu fett und da reichen mir kleinen LPC11xx oder 13xx. Mittlerweile gibt es aber auch die STM32F103 beim Chinesen, so ein http://de.aliexpress.com/item/STM32F103C8T6-ARM-STM32-Minimum-System-Development-Board-Module-ForArduin/32282374854.html Board (mit 64 Karat Flash!) habe ich gerade hier liegen. Die kommen damit preislich schon in die Arduino Nano Region. Die 103er haben aber nur 16 Bit Timer, da treibt mich gerade ein Fehler in der mbed lib in den Wahnsinn, die 32 Bit Timer/Counter im LPC sind echt ein Seegen! Warum ist man bei ST so geizig und macht die nicht auch alle gleich 32 Bit breit?
Dr. Sommer schrieb: > Leider nicht. Weißt du ob der Lauterbach schneller ist? Ich habe auch keinen Benchmark zur Hand. Außerdem muss man sich die genauen Anwendungsfälle anschauen. Geht es bei der Geschwindigkeit um das Programmieren eines internen Flashes? Oder um das Auslesen von Speicherinhalten? Oder Traces? Ein riesiger Vorteil der Lauterbach-Debugger besteht darin, dass man neben den eingebauten Algorithmen zum Programmieren/Auslesen von Speicherinhalten auch eigene im Speicher des Prozessors ablegen kann (sog. Target Based Programming). Damit kommt man auch an unkonventionell angeschlossenen Speicher heran. Das ist bei den heutigen vollintegrierten Microcontrollern vielleicht nicht so relevant, bei Systemen mit extern angeschlossenem Speicher aber ggf. schon. > Es scheint allgemein wenig Informationen zu dem im Netz zu geben. > Wäre auch ein Argument dagegen... ;-) Die mitgelieferte bzw. für Kunden per Download erhältliche Dokumentation einschließlich Beispielcode bzw. -skripten ist schon so umfangreich, dass da kaum noch Fragen offen bleiben. > Scheint auch hier im Forum bzw. allgemein der > Hobby-Community kaum vertreten zu sein. Das ist hauptsächlich eine Kostenfrage. Je nach Trace- oder Logikanalysefunktion kostet die Hardware ca. 2kEUR bis 10kEUR. Zudem muss man für jede Prozessorkernfamilie eine eigene Lizenz kaufen, d.h. ARM7 benötigt eine Lizenz, ARM9 eine weitere, Cortex-M noch eine, Cortex-A eine, jeweils mit Kosten von rund 1kEUR. Lauterbach ist aber recht großzügig mit Testlizenzen.
W.S. schrieb: > Diese Art zu diskutieren ist sachlich falsch. Ich erläutere es dir mal: falsch finde ich es Leuten die nach einer IDE fragen das makefile zu predigen und sie als Daddler zu bezeichnen wenn sie ein anderes Werkzeug wählen. IDE oder makefile sind Werkzeuge die man im Hobbybereich selber wählen kann und erfreulicherweise gibt es da heute eine große Auswahl für die man früher viel Geld hinlegen musste.
Andreas S. schrieb: > Geht es bei der Geschwindigkeit um > das Programmieren eines internen Flashes? Oder um das Auslesen von > Speicherinhalten? Oder Traces? Ersteres, und die Geschwindigkeit von Step-by-Step-Debugging würde ich sagen... Andreas S. schrieb: > Ein riesiger Vorteil der Lauterbach-Debugger besteht darin, dass man > neben den eingebauten Algorithmen zum Programmieren/Auslesen von > Speicherinhalten auch eigene im Speicher des Prozessors ablegen kann Ja, das klingt in der Tat cool... Andreas S. schrieb: > Die mitgelieferte bzw. für Kunden per Download erhältliche Dokumentation > einschließlich Beispielcode bzw. -skripten ist schon so umfangreich, > dass da kaum noch Fragen offen bleiben. Tja, ich hätte mir erstmal eine Übersichts-Website mit den Features gewünscht, und kein 1000-Seitiges PDF. Gibts beim JLink ja auch :-) Andreas S. schrieb: > Das ist hauptsächlich eine Kostenfrage. Je nach Trace- oder > Logikanalysefunktion kostet die Hardware ca. 2kEUR bis 10kEUR. Aah, damit hat sich das für den Hobbybereich wohl erledigt?! W.S. schrieb: > Wenn du hingegen ein Entwicklungsingenieur sein willst, der "sich mit > ARMs befaßt", dann mußt du dich zwangsweise mit den Innereien des Chips Man muss aber nicht als allererstes alle Details lernen. Fängt man erst mit den Innereien des IC's an, und damit wie man den Compiler per Batch aufruft, kommt man nie auf einen grünen Zweig. Die Motivation hat sich dann (für den Hobby-Entwickler) auch schnell erledigt. Es ist durchaus sinnvoll, es sich ersteinmal einfach zu machen mit IDE's und Libraries, und sich die Grundlagen der Peripherie anzusehen (wie zB die Gemeinheiten des RCC beim STM32), und dann stück für stück vorzuarbeiten. Es kriegt keiner eine Medaille weil er von Anfang an den kompliziertesten Weg gewählt hat...
Jojo S. schrieb: > Im Kern ja, aber die Peripherie ist unterschiedlich und vor allem wie > der interne Flash programmiert wird. > Den Compiler kann man schon für µCs anderer Hersteller nutzen, aber der > Support beim Debuggen fehlt OK, das macht Sinn.
W.S. schrieb: > Aber aus böser Erfahrung weiß ich, daß die meisten, die so anfragen, > sich später als Entwicklungsingenieure bewerben und in vollstem Stolz > von sich behaupten, daß sie sich mit 32 Bit Controllern bestens > auskennen Ich hatte auch einmal ganz üble Erfahrungen mit einem externen Mitarbeiter gemacht, der sich angeblich genau mit dem damals eingesetzten Mikroprozessor (AT91RM9200) auskannte und angeblich auch ein Linux-Experte war. Im Laufe des Projektes zeigten sich jedoch so eklatante Wissenslücken, dass das Projekt komplett in die Hose gegangen war. Glücklicherweise hatten wir entsprechende Klauseln in den Entwicklungsvertrag aufgenommen, so dass zu dem fachlichen Desaster für mich nicht auch noch ein finanzielles hinzukam. Das größte Problem dieses Mitarbeiters war seine Lernresistenz, d.h. er hatte ziemlich wirre Vorstellungen von der Funktionsweise des Prozessors und sah es als Fehler des Prozessors an, wenn sich dieser nicht so verhielt wie von ihm erwartet. Selbiges traf noch mehr auf Linux zu. Ständig glaubte er, eklatante Fehler im Kernel gefunden zu haben, aber er selbst war bloß nicht in der Lage, die APIs richtig zu verwenden. Der Typ hatte damals rund 30 Jahre Berufserfahrung, d.h. natürlich einen erheblichen Teil auf uralten UNIX-Systemen und Mainframes.
Andreas S. schrieb: > Grenzwertig sind aber in der Tat Produkte, deren Open-Source-Herkunft > verschleiert und/oder die Lizenzbestimmungen nicht eingehalten werden. Darum ging es mir hier. Ich kaufe weder Raubkopien von kommerzieller Software noch benutze ich Software, die eine FOSS Lizenz verletzt. Da ist es mir völlig gleichgültig, dass beide Raubkopien ja doch "kostenlos" sind, und mit "Freeware" hat weder das eine noch das andere etwas zu tun. Ich achte die Lizenzen (so ungewöhnlich das manchen auch scheinen mag.) Daher wollte ich wissen, ob ich das mit CooCox richtig einschätze. Nun sind ganz nebenbei aus diesem Thread noch viele Empfehlungen für den ARM-Einstieg und interessante IDEs herausgekommen. Danke dafür an: Jojo S. (jojos) Dr. Sommer (Gast) Total Eclipse (Gast) m. keller (Gast) kderh (Gast) (auch wenn TrueStudio auf meinem OS vermutlich nicht laufen wird)
AVR-Bastler schrieb im Beitrag #4429509: > Ich kaufe weder Raubkopien von kommerzieller Software noch benutze ich > Software, die eine FOSS Lizenz verletzt. Oha, das ist aber ein hoher Anspruch. Ich bezweifele, dass sich die zweite Aussage wirklich durchhalten lässt. Wie die Vergangenheit gezeigt hat, haben sich auch schon große Markenhersteller entsprechende Lizenzverstöße erlaubt. Die allermeisten Fälle werden auch komplett unentdeckt bleiben, nämlich dann, wenn nur eine Bibliothek rechtswidrig eingesetzt wird und die Verwendung dieser Bibliothek von außen nicht erkennbar ist. Da bleibt eigentlich nur der vollständige Verzicht auf jegliche Elektronik. > Da ist es mir völlig > gleichgültig, dass beide Raubkopien ja doch "kostenlos" sind, und mit > "Freeware" hat weder das eine noch das andere etwas zu tun. > Ich achte die Lizenzen (so ungewöhnlich das manchen auch scheinen mag.) Neben den recht einfach zu definierenden Urheberrechtsverstößen können aber auch noch andere Schutzrechte beeinträchtigt sein, z.B. Patente oder Muster. > Daher wollte ich wissen, ob ich das mit CooCox richtig einschätze. Deine Sichtweise auf CooCox ist rassistisch geprägt. Nur weil es sich mittlerweile um ein chinesisches Projekt handelt, unterstellst Du automatisch Rechtsverstöße. Weißt Du, aus welchem anderen Land außer China die meisten Plagiate stammen? Richtig, Deutschland! Man wird aber in der Tat niemals eine international einheitliche Würdigung geistigen Eigentums erreichen können. In vielen asiatischen Kulturen gilt die Anfertigung von Plagiaten als Ehre gegenüber dem ursprünglichen Ersteller. Ganz im Gegensatz hierzu steht die US-amerikanisch geprägte Sichtweise, die auch in Deutschland stark dominiert, dass jeder noch so kleine Furz in bare Münze umsetzbar sein muss. Meine persönliche Einsstellung hierzu ist, dass wir ein starkes Urheber- und Markenrecht benötigen, um konkrete Produkte zu schützen und Nachahmer erkennen zu können. Im Gegenzug sollte der Patentschutz sehr viel schwächer sein, d.h. Trivialpatente dürfen sich nicht lohnen. Die Dauer des Patentschutzes muss sich zudem an dem Zeitbedarf für die Erfindung orientieren.
Dr. Sommer schrieb: > Nicht auf das wirre Geschreibsel von W.S. hören Danke auch für diesen Tipp - wenngleich Du ihn selbst danach nicht sehr konsequent befolgst... ;-) Ich folge diesem Forum schon eine ganze Weile. Es gibt viele gute Beiträge und viele sachkundige Teilnehmer. Zwar wird es manchmal durch gewisse andere Teilnehmer sehr anstrengend - damit meine ich nicht (nur) oder nicht einmal speziell W.S. Ich nehme an, hier ist einfach eine Sektion des "Fanclubs für leistungsloses Grundeinkommen" beheimatet. Aber man muss ja auch die gesellschaftliche Funktion eines solchen Forums berücksichtigen. "Inklusion" nennt man das wohl heute. (Man stelle sich nur vor, was die armen Teufel ohne Forum so treiben würden... Eisenbahnschienen durchsägen, Flüchtlingsheime anzünden, abends ohne Hose durch den Stadtpark laufen...)
AVR-Bastler schrieb im Beitrag #4429317: > Ich denke, die > ARM sind alle gleich? Es gibt keine "die ARM". Gleich ist bei Microcontroolern, welche auf dem selben ARM Cortex basieren eben nur der. Das heisst die Controller sind änlich, denn die Perepherie um diesen CPU Kern herum gestaltet jeder anders.
W.S. schrieb: > Die Alternative wäre ein Seggerscher J-Link aus China oder ein > J-Link-Edu nebst geklauter Flash-Lizenz Hust...dir ist klar das Segger hier auch mitliest? Kannst ja selber entscheiden inwieweit sowas für dich strafrechtlich relevant ist. Davon abegesehen, das bei 50,- Euro für eine J-link EDU es keinen Grund mehr gibt sich einen Clon aus China zu besorgen.
Guest schrieb: > Hust...dir ist klar das Segger hier auch mitliest? Logo. Was meinst du eigentlich, weswegen ich elleweil auf das Programmieren der Chips mittels eingebautem Bootlader hinweise? Jaja, ich bin ein großer Freund von Chips mit fest eingebautem Bootlader - und das aus zwei mir wichtigen Gründen: 1. Der Bootlader weiß ganz genau, wie eben dieser Chip zu programmieren ist. 2. Der Bootlader ist im Lieferumfang des Chips enthalten und ein jeder kann ihn benutzen ohne dafür irgendwas zu bezahlen. und 3.: Punkt 1 und 2 sind bei allen JTAG/SWD-Lösungen nicht enthalten, sondern eher das Gegenteil. Klaro? Aber - und das stellt sich beim Lesen dieses threads mal wieder heraus, ist der Eröffnungspost nicht wirklich ernst gemeint. Stattdessen geht es wie immer vorrangig um das Ausprobieren von IDE's, welche die hippeste IDE ist. Na denne, macht mal... W.S.
Etwas OT... A. K. schrieb: > Andere verwenden aber auch GCC als Grundlage. Und nicht immer so, wie > GNU sich das gedacht hat. Microchip tut das in etwas grenzwertiger Form, > die an Methoden von Rechtsverdrehern erinnert. Volle Zustimmung > Deren 16- und 32-Bit > Umgebungen basieren auf GCC, dem sie zusätzliche Optimierungen > beigebracht haben, ohne diese als Quellcode zu veröffentlichen. Quelltexte gibt es schon http://www.microchip.com/pagehandler/en-us/devtools/dev-tools-parts.html ganz unten unter Source Archives > Das > haben sie dadurch legal erreicht, indem sie den Compiler zwischendurch > quasi aufbrechen, die Optimierungen mit einem separaten Programm auf dem > Zwischencode durchführen, um dann mit dem Rest vom GCC darauf basierend > wieder weiter zu machen. Soviel zu "Chinesen im Geiste". Anscheinend reicht es den Compiler entweder selbst zu erstellen (mit entsprechenden Anpassungen) oder einen der im Netz auffindbaren Patche zu nutzen, um die "Erweiterungen" von Microchip, die wohl nur die Optimierungen bei mangelnder Lizenz ausschalten, zu umgehen...
Arc N. schrieb: > Quelltexte gibt es schon > http://www.microchip.com/pagehandler/en-us/devtools/dev-tools-parts.html > ganz unten unter Source Archives Den aus GPL Quellen abgeleiteten Teil müssen sie veröffentlichen. Jener Microchip-eigene Optimizer, auf den ich mich beziehe, ist aber nicht Teil des Exe-Programms des Compilers, sondern in ein separates Exe-Programm ausgelagert. Dadurch entfällt die Pflicht zur Veröffentlichung des Quellcodes dieses Teils. > Anscheinend reicht es den Compiler entweder selbst zu erstellen (mit > entsprechenden Anpassungen) oder einen der im Netz auffindbaren Patche > zu nutzen, um die "Erweiterungen" von Microchip, die wohl nur die > Optimierungen bei mangelnder Lizenz ausschalten, zu umgehen... Der Lizenzcheck selbst kann aus Lizenzgründen nicht Teil eines Exe-Programms sein, das aus den GCC Quellen abgeleitet ist - ihn als Quellcode zur Verfügung zu stellen wäre einigermassen absurd. Folglich ist der Lizenzcheck auch ein separates Exe-Programm. Dessen Ergebnis entscheidet darüber, ob der Compiler mit voller oder eingeschränkter Lizenz arbeitet. So wars jedenfalls vor einigen Jahren.
:
Bearbeitet durch User
W.S. schrieb: > Aber - und das stellt sich beim Lesen dieses threads mal wieder heraus, > ist der Eröffnungspost nicht wirklich ernst gemeint. Doch, er war ernst gemeint. Du hast die Frage nur nicht gelesen. (Kleiner Tipp: Fragen stehen in den Sätzen, die mit diesem Zeichen enden: "?".) Statt dessen hast Du eine Frage beantwortet, die ich nicht gestellt hatte, von der Du Dir aber gewünscht hast, dass ich sie gestellt hätte, nämlich wie man sich am besten dem Thema ARM nähert. Damit hast Du eine von mir nicht beabsichtigte Sekundär-Diskussion angestoßen, die aber am Ende durch die Beiträge der anderen Nutzer tatsächlich auch für mich fruchtbar und informativ war. Dafür danke ich Dir. Nach Deiner freundlichen Einleitung: W.S. schrieb: > Hä? > > Was willst du eigentlich? habe ich Dich jedoch zunächst ignoriert. Meine durchaus ernst gemeinte Frage war, ob CooCox und CoIDE eine Lizenz verletzen. Das mag für Dich nicht wichtig oder sogar unverständlich sein, weil geklaut ja schließlich nix kostet, aber für mich ist es wichtig. Denn - Raubkopie - Freeware - Open Source sind drei völlig verschiedene Dinge. Ja, alle drei sind "kostenlos". Aber rechtlich sind Welten dazwischen. Und auch wenn ich mich für ARM interessiere - so "arm" bin ich nicht, dass ich es mir nicht leisten könnte, das Recht als Grundlage unserer Gesellschaft zu achten. W.S. schrieb: > Als nächstes würde ich dir zur Demoversion vom "Keil" raten Wird auf meinem OS wohl nicht laufen. W.S. schrieb: > brauchst du nur noch eine simple Batchdatei zum > Kompilieren und fertig ist die Soße. Ja, ich weiß. Habe ich auch mal gemacht. Irgendwann in den 80er Jahren des vergangenen Jahrhunderts. Komplilieren und Linken auf der Kommandozeile. Waaahnsinnig spannend. Leider wenig abwechslungsreich. Inzwischen bin ich faul genug für eine IDE. Ja, ich gebe es offen zu: Ich bin sogar so faul, dass ich bei manchen Programmier-Aufgaben Bibliotheken benutze, statt alles komplett neu zu schreiben! Hineinschauen kann man ja trotzdem mal- das soll auch bei der Anwendung von Bibliotheksfunktionen helfen. W.S. schrieb: > aus böser Erfahrung weiß ich, daß die meisten, die so anfragen, > sich später als Entwicklungsingenieure bewerben Nein, ganz sicher nicht. Man weiß zwar nie, was einem im Leben noch so alles zustoßen mag, Schicksalsschläge, sozialer Abstieg,... und ich möchte auch den hier vetretenen Entwicklungsingenieuren nicht zu nahe treten, aber ich kann mir wirklich kein Szenario vorstellen, in dem ich mich irgendwo als "Entwicklungsingenieur" bewerben würde.
Und noch eine Antwort auf einen O.T. Beitrag, eigentlich alles für den Bereich "Gesellschaft & Soziales": Hallo Andreas, Andreas S. schrieb: > Ich bezweifele, dass sich die > zweite Aussage wirklich durchhalten lässt. Sie lässt sich genauso leicht durchhalten wie die erste. Auch die Verwendung von Raubkopien, raubkopierten Teilen oder Plagiaten kann verschleiert werden. Daraus aber abzuleiten, dass man dann genauso gut Raubkopien kaufen kann, weil man auch sonst ja nicht hundertprozentig sicher vor Betrug sein kann... schräg, oder? Mit derselben Logik könnte man ja einen Ladendiebstahl damit rechtfertigen, dass es ja nicht auszuschließen ist, dass es sich sowieso nur um Hehlerware gehandelt hat. Andreas S. schrieb: > Deine Sichtweise auf CooCox ist rassistisch geprägt. Nur weil es sich > mittlerweile um ein chinesisches Projekt handelt, unterstellst Du > automatisch Rechtsverstöße. Das ist ja ein dicker Hund! Ich habe auf www.coocox.org quelloffene Software gefunden, die als "free/open" angeboten wird. Die Seite hat eine .org Domain, nicht .cn. Dann stelle ich fest, dass die zum größten Teil aus der Linux-Welt stammenden quelloffenen Komponenten nur als Windows-Executable angeboten werden. Ist ja kein Problem - da nimmt man sich die Source und kompiliert das eben für die eigene Umgebung neu. Allerdings habe ich vergeblich nach den Quellen gesucht. Nun kann es ja sein, dass ich sie nur nicht gefunden habe. Nicht alle Webseiten sind übersichtlich... Wie Du aus meiner Frage nun Rassismus herleitest, bleibt Dein Geheimnis. Vielleicht solltest Du Deine eigenen vorschnellen Schlüsse noch einmal hinterfragen, bevor Du auf den Knopf "Absenden" klickst. Über die mangelnde Patentfähigkeit von Trivialpatenten, lebenden Organismen, in der Natur vorhandener Information usw. können wir uns sicher verständigen. Aber Recht darf nicht vom "kulturellen Hintergrund" abhängen. Sonst wären Ehrenmorde nicht strafbar. Aber wenn ich jemanden umbrächte, wäre es strafbar. Es sei denn es war ein Grüner, und ich kann nachweisen, dass ich ein CSU-Parteibuch habe. Dann wird man wieder sagen "Bayern halt... kulturelle Unterschiede." Andreas S. schrieb: > Die > Dauer des Patentschutzes muss sich zudem an dem Zeitbedarf für die > Erfindung orientieren. Das wiederum halte ich für völligen Blödsinn. es würde dazu führen, dass eine Bremsbirne, die 20 Jahre gebraucht hat, um etwas patentierbares zuwege zu bringen, einen höheren Patentschutz genießt, als eine Genius, der pro Tag 10 gute Einfälle hat und verwirklicht. Leistung = Arbeit / Zeit und eben nicht Leistung = Arbeit * Zeit Das ist dasselbe Argument, mit dem der Arbeiter, der jeden Tag Kisten von links nach rechts und wieder von rechts nach links schleppt, voll Hass und Neid auf den "Manager" schaut, der diese sinnlose Tätigkeit einfach streicht. Der Arbeiter hat schließlich den ganzen Tag gearbeitet, und dieser Schnösel da sitzt bloß in seinem Büro...
A. K. schrieb: > Folglich > ist der Lizenzcheck auch ein separates Exe-Programm. Dessen Ergebnis > entscheidet darüber, ob der Compiler mit voller oder eingeschränkter > Lizenz arbeitet. So wars jedenfalls vor einigen Jahren. Das tut der Lizenzcheck auch noch... Ohne direkt auf die möglichen Umgehungen zu verlinken: Im Source des Gcc ist gut auffindbar u.a. untergebracht: Laden des Lizenzchecksprogramms, Testen ob dessen Hash zu dem im Quelltext vorgegebenen Hashwert passt, falls ja, Lizenzprogramm ausführen und je nach Rückgabewert die entsprechende(n) Lizenz(en)/Optimierungsstufe(n) freischalten bzw. falls etwas davon nicht funktioniert hat die Optimierungen ausschalten und jeweils entsprechende Meldungen ausgeben... Der Quelltext des Gcc darf entsprechend der GPL verändert und weitergegeben werden...
:
Bearbeitet durch User
Arc N. schrieb: > Lizenzchecksprogramms, Testen ob dessen Hash zu dem im Quelltext > vorgegebenen Hashwert passt, Der Check mit dem Hashwert war früher noch nicht drin.
A. K. schrieb: > Arc N. schrieb: >> Quelltexte gibt es schon >> http://www.microchip.com/pagehandler/en-us/devtools/dev-tools-parts.html >> ganz unten unter Source Archives > > Den aus GPL Quellen abgeleiteten Teil müssen sie veröffentlichen. Jener > Microchip-eigene Optimizer, auf den ich mich beziehe, ist aber nicht > Teil des Exe-Programms des Compilers, sondern in ein separates > Exe-Programm ausgelagert. Dadurch entfällt die Pflicht zur > Veröffentlichung des Quellcodes dieses Teils. Beim XC32 finde zumindest ich nichts in diese Richtung. Bin aber auch eher weniger mit den gcc-Quelltexten vertraut... Mit grep und anhand der offensichtlichen Dateinamen ist nur die Lizenzteststelle auffällig (was zumindest mit anderen Quellen im Netz übereinstimmt...)
Ich hatte das vor etlichen Jahren beim Compiler für die dsPIC30 festgestellt. Microchip hatte eine eigene Optimierung zur Zusammenfassung von gleichen Codeschnipseln eingebaut, um Code zu sparen (auch im damaligem Compiler für PIC18 fand sich diese Optimierungtechnik). Ob die auch in der PIC32 Version drinsteckt weiss ich nicht.
:
Bearbeitet durch User
np r. schrieb: > Doch, er war ernst gemeint. Du hast die Frage nur nicht gelesen. > (Kleiner Tipp: Fragen stehen in den Sätzen, die mit diesem Zeichen > enden: "?".) Oh danke für die Aufklärung. Aber es bleibt dabei: Dein Eröffnungsbeitrag (sofern du denn überhaupt der TO bist) war ganz sicher nicht wirklich ernst gemeint. Ich zitiere mal: "ich spiele gerade mit dem Gedanken, aus der AVR-Welt kommend die Nase mal in ARM zu stecken." Ah ja, die Nase in Arm stecken. Bin beeindruckt von soviel Präzision in der Aussage. np r. schrieb: > Statt dessen hast Du eine Frage beantwortet, die ich nicht gestellt > hatte, von der Du Dir aber gewünscht hast, dass ich sie gestellt hätte, > nämlich wie man sich am besten dem Thema ARM nähert. Ähemm.. eben genau DAS hatten wir doch im Eröffnungspost. Also, wo willst du denn deine Nase hineinstecken, he? > Nach Deiner freundlichen Einleitung: > W.S. schrieb: >> Hä? >> >> Was willst du eigentlich? > > habe ich Dich jedoch zunächst ignoriert. Das ist dein Problem - nicht das meinige. Wer da meint, es ohne meinen Rat besser zu können.. bittesehr, nur zu, rein theoretisch führen 1000 Wege nach Rom. np r. schrieb: > Komplilieren und Linken auf der > Kommandozeile. Waaahnsinnig spannend. Leider wenig abwechslungsreich. Und wer es partout nicht einfach und geradlinig mag, sondern lieber verzwickt, dem sei auch dieses gegönnt. Fazit: Dein Interesse an "Nase in Arm stecken" ist gleich null, stattdessen willst du eine Diskussion über CooCox und CoIDE und lizenzrechtliche Themen. Warum schriebest du das denn nicht gleich im Eröffnungspost? (wieder vorausgesetzt, du bist dessen Schreiber) W.S.
Lieber W.S., > Ah ja, die Nase in Arm stecken. Bin beeindruckt von soviel Präzision in > der Aussage. Ja, endlich! Hier hast Du es endlich erfasst . aber leider selbst nicht gemerkt. Es war eine Aussage, keine Frage. Wenn ich schreibe: "Heute ist das Wetter so schlecht, da möchte ich wieder etwas löten. Welche Lötstation nehmt ihr?" dann ist der einleitende Teil über das Wetter eine Aussage, möglicherweise nicht sehr präzise, aber belanglos, denn eben nur eine Einleitung. Die Frage ist das Ding mit dem Fragezeichen "?". Du hast also auf die Aussage geantwortet anstatt auf die Frage. weil Dir die Aussage zu unpräzise war und Du unbedingt belehren wolltest! LOL :-D Nein, sorry. Man sollte da nicht lachen. So ein Verhalten ist ja eher traurig und kann schnell einsam machen. > stattdessen willst du eine Diskussion über CooCox und CoIDE und lizenzrechtliche > Themen. > Warum schriebest du das denn nicht gleich im Eröffnungspost? Genau das habe ich getan. Dies war nämlich die Frage und mit einem Fragezeichen deutlich gekennzeichnet. Du siehst: Wer lesen kann ist klar im Vorteil. > sofern du denn überhaupt der TO bist Fragen stelle ich oft anonym. Da ist ja nur die Frage wichtig und nicht, wer sie stellt. Wenn ich Dich persönlich aneiere, dann mache ich das mit Login. Ich weiß, dass manche andere das genau umgekehrt handhaben, aber das mag ich nicht.
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.