Hallo zusammen!
Ich habe es geschafft, die CodeSizeLimitation des aktuellen Atollic
TrueStuio Lite v5.3.0 zu umgehen, und möchte euch nun an meinem Wissen
teilhaben lassen.
Ich habe bisher ausschließlich Atollic verwendet, um Mikrocontroller von
STM zu programmieren. Die bekannte Eclipse-Umgebung macht die Arbeit
sehr angenehm, zusätzlich sind auch schon alle Headers der Controller,
Compiler für die Architektur, und Beispielcode für Demoboards
integriert. Für kleine Projekte ist Atollic also die optimale Lösung.
Bisher habe ich größere Projekte in Einzelkomponenten unterteilt und
einzeln kompiliert und geflasht. Mit modifiziertem Linkerfile bekam jede
Komponente seinen eigenen Flashsektor, die Hauptapplikation konnte diese
mittels Funktionstabellen anspringen. Sehr aufwändig zu programmieren,
managen und kompilieren.
Dabei ist mir immer wieder folgendes aufgefallen:
Der Compiler kompiliert immer alle Dateien ohne meckern, egal wie groß
und wie viele. Erst der Linker implementiert die Codesize Limitation!
Wenn man nun (rein hypothetisch versteht sich ^^) den Linker von Atollic
gegen einen GCC-Linker austauschen würde, müsste es funktionieren!
GCC für ARM herunterladen, zum Beispiel diesen hier:
https://launchpad.net/gcc-arm-embedded
kopiere nun
(backup des original-linkers machen!!!)
... und schon kann man ein paar minuten ohne CodeSizeLimitation
kompilieren und linken.
Eben nur so lange, bis Atollic TrueStudio diese Veränderung auffällt und
die IDE wegen "corrupt installation" beendet.
Wenn man sich aber nun zwei *.bat-Dateien schreibt (eine zum kopieren
des gcc-linkers, die zweite zum wiederherstellen des
original-zustandes), diese im Projekt als Pre- und Post-Buildsteps
angibt, ........ Achievement unlocked!
Das wird sicherlich gegen irgendwelche Lizensvereinbarungen sprechen,
daher kann ich es durchaus verstehen, wenn dieser Beitrag in absehbarer
Zeit gelöscht wird.
Ich hoffe aber, dass sich dieses Wissen bis zu jenem Zeitpunkt bereits
ausreichend verbreitet hat.
Viel Spass beim Ausprobieren!
~Lil B
Ich habe das bei mir mal ausprobiert. Keine Ahnung wieso du bei dir
Minuten Zeit hast, aber bei mir stellt TrueStudio(5.3) schon nach etwa
20 Sekunden fest, dass die Installation korrupt ist.
Das ist leider zu kurz und damit nicht nutzbar
Lil B schrieb:> Das wird sicherlich gegen irgendwelche Lizensvereinbarungen sprechen,
Atollic selbst verstoßt wahrscheinlich gegen die Lizenzbestimmungen des
gcc, auf jeden Fall aber gegen die guten Sitten und gegen jeden Rest von
Anstand und Moral mit ihrem schäbigen rip und Deine Methode ist
moralisch gerechtfertigte Notwehr.
Vielen Dank für diesen Tipp!
Funktioniert nach wie vor!
Kann mann denn nicht einfach unter
Project->Properties->C/C++-Build->Settings/C Linker einen eigenen Linker
definieren?
Quasi den aufruf umbiegen. So dass weiterhin die bekannte ld.exe
vorhanden ist.
Oder wo wird definiert, dass es die ld.exe ist?
Atollic für ARM ist jetzt ohne Codesize-Beschränkung kostenlos nutzbar:
A commercial-quality development tool that everyone can standardize on;
a professional tool based on open standards, that is free to download
and use,
and better than anything else available!
Free to download. Free to use. Free to share. No code size limits!
http://timor.atollic.com/truestudio/
Pete K. schrieb:> Atollic für ARM ist jetzt ohne Codesize-Beschränkung kostenlos nutzbar:
Gleich mal ausprobieren.
Kann eigentlich nur besser werden nach CooCox.
CooCox versucht bei jedem Start gleich mal das ganze Internet
mit auf die Platte zu ziehen, oder umgekehrt wird gleich mal alles
was man selbst auf der Platte hat ins Internet gesaugt.
- Gut wer eine Firewall hat die das abblockt.
- Schlecht wer eine Firewall hat die das abblockt, denn der muss
warten auf Godod bis der "Sauger" aufgibt eine Verbindung zu versuchen.
Ich vertraue dieser anonymen Kreation kein bisschen, abstellen
(offline arbeiten) kann man das Zeugs auch nicht .... was die
Erfinder sich bei so etwas denken ist mir schleierhaft.
Wie sieht es denn mit dem debuggen in der freien Version aus? Ich habe
in den Unterschieden zur Pro Version gelesen das die Lite zB kein
Variablen Live Watch erlaubt. Heisst das ich bekomme beim Ausführen von
Einzelschritten keine Variablenwerte angezeigt?
Mit Yagarto als Alternative habe ich mich schon ewig nicht mehr
beschäftigt, gibt es da gute Debugger PlugIns?
Habe den Moloch mit seinen knapp 4 GB installiert. Projekt anlegen und
kompilieren klappt sofort, aber beim Debugstart werde ich mit
Fehlermeldungen zugeworfen.
Ok, Debug starten übe den Debug Button geht erst wenn man einmal mit
Debug Config gestartet hat, jetzt geht es.
Ein ST-Link vom F4-Discovery wird erkannt und mein LPCLink2 im J-Link
Modus geht auch (musste aber IAR J-Link anwählen, Segger J-Link wirft
Fehlermeldungen).
Steppen+Variablen+Register anzeigen geht auch, dieses LiveView ist wohl
noch was anderes (Variablen Anzeige beim laufenden Programm?), sieht
erstmal brauchbar aus.
Es bleibt das nervige Upgrade Nagging beim Starten, kann man das
irgendwo abstellen? Ausser durch Pro kaufen?
Flip B. schrieb:>>Live variable /expression Watch*>>*1 Requires a SEGGER J-Link probe and a Cortex-M target device> ist für mich eh raus.
Wenn man eh einen J-Link hat dann kann man auch jederzeit die konstenlos
dazu mitgelieferte J-Scope Software verwenden um live Variableninhalte
anzuzeigen und zu plotten, die geht auch komplett standalone ohne IDE.
Aufgrund Kundenwunsch bearbeite ich gerade ein STM32F4-Projekt mit
Atollic.
Bisher habe ich STM32 auf IAR bzw. CooCox beackert.
Das Atollic Lite 5.4.0 fühlt sich gegenüber CooCox 1.7.8 garnicht so
übel an.
Der alberne Nag-Screen will nach Hause telefonieren, dagegen hilft die
Firewall.
Die IDE selbst wirkt agiler als CooCox.
Die Tastenbelegungen sind anders (kann man wohl einstellen)
Beim Einstieg hatte ich folgendes Problem, vielleicht hat jemand einen
Tipp?
- ich habe keinen Switch gefunden, damit der Compiler für Includes das
komplette Projektverzeichnis rekursiv durchsucht. Nach Internet und
Doku-Suche behelfe ich mir momentan durch das manuelle Einstellen der
einzelnen Suchpfade. Das wäre bei der Portierung von größeren Projekten
(sagen wir mal 1000 Quellfiles in 200 Ordnern), gelinde gesagt, lästig
Mich würde die Meinung eines Eclipse-Experten interessieren, welche
Vorteile Atollic-Eclipse bei der STM32-Entwicklerei gegenüber Eclipse
hat.
Schönes Wochenende,
Marcus
Lil B schrieb:> Bisher habe ich größere Projekte in Einzelkomponenten unterteilt und> einzeln kompiliert und geflasht. Mit modifiziertem Linkerfile bekam jede> Komponente seinen eigenen Flashsektor, die Hauptapplikation konnte diese> mittels Funktionstabellen anspringen. Sehr aufwändig zu programmieren,> managen und kompilieren.
Ich frage mich wieso man sich einen derartigen Aufwand macht, wenn es
inzwischen genug freie IDE gibt, die ähnlich sind? ich habe mir mal die
Mühe gemacht für Rowley Crossworks Cracks und Keygens herunter zu laden
vor einigen Jahren. Lief auch alles, bis ich schliesslich 250 Laschen
ausgegeben habe, um auch Updates zu kriegen. Und bis ich dann merkte,
dass es fast ein Dutzend freie IDE gibt, die dem Ganzen in Nichts
nachstehen. Rowley benutzt auch den GCC aber eigene Libraries nachdem
sie eine gerichtlinie Auseinandersetzung hatten.
>>CooCox versucht bei jedem Start gleich mal das ganze Internet>>mit auf die Platte zu ziehen, oder umgekehrt wird gleich mal alles>>was man selbst auf der Platte hat ins Internet gesaugt.
Darum habe ich diesen Shice auch direkt wieder gelöscht, das nervte
sowas von total, dieses ewige Rumdaddeln im Internet.
EmBitz oder EmWin und Du bist glücklich!"
Marcus H. schrieb:> Das wäre bei der Portierung von größeren Projekten> (sagen wir mal 1000 Quellfiles in 200 Ordnern), gelinde gesagt, lästig
Sowas riesiges würde ich nicht mehr der IDE der jeweiligen Tagesmode
anvertrauen, bei sowas würde ich den Build-Vorgang scriptgesteuert
ablaufen lassen, sprich: Makefile.
heutige IDEs (wie zum Beispiel Eclipse und einige andere IDEs
wahrscheinlich auch und auch IDEs der Zukunft) sind in der Lage den
Output beim Build-Vorgang zu parsen und sich dann anhand dessen was sie
da sehen vollständig selbst zu konfigurieren (include-Pfade und
definierte Symbole für jede zum Projekt gehörige Datei). Damit läuft
dann der Import eines bestehenden Projekts mit 3 Mausklicks und einem
make clean all bei dem die IDE lernt wo sich alle Header befinden und
welche defines gegeben sind.
Christian J. schrieb:> EmBitz oder EmWin und Du bist glücklich!
Stellt sich dann gleich dieselbe Frage: was ist der Vorteil ggü. einer
selbst zusammengestellten Umgebung? Ist zwar ein gewisser Aufwand, es
gibt mittlerweile aber gute Tutorials dazu.
Bernd K. schrieb:> Marcus H. schrieb:>> Das wäre bei der Portierung von größeren Projekten>> (sagen wir mal 1000 Quellfiles in 200 Ordnern), gelinde gesagt, lästig
Ich bin Dienstleister, mir sagt der Kunde, was er haben möchte. Ich
mache zwar ggf. Vorschläge, für einen entsprechend großen Auftrag
installiere ich jedoch gerne eine neue IDE.
> heutige IDEs (wie zum Beispiel Eclipse und einige andere IDEs> wahrscheinlich auch und auch IDEs der Zukunft) sind in der Lage den> Output beim Build-Vorgang zu parsen und sich dann anhand dessen was sie> da sehen vollständig selbst zu konfigurieren (include-Pfade und> definierte Symbole für jede zum Projekt gehörige Datei). Damit läuft> dann der Import eines bestehenden Projekts mit 3 Mausklicks und einem> make clean all bei dem die IDE lernt wo sich alle Header befinden und> welche defines gegeben sind.
Naja, CooCox-Eclipse macht das, ohne dass ich von Hand makefiles
erstellen muss.
Nun meine Frage ist, was ich tun muss, damit das mächtigere
Atollic-Eclipse das auch macht.
Marcus H. schrieb:> Naja, CooCox-Eclipse macht das, ohne dass ich von Hand makefiles> erstellen muss.
Echt? Welche Arten von Eclipse-fremden Fremd-Projekten kann CooCox denn
importieren und dabei die notwendigen Compiler-Optionen, Pfade und
Defines vollautomatisch erkennen?
Bernd K. schrieb:> Marcus H. schrieb:>> Naja, CooCox-Eclipse macht das, ohne dass ich von Hand makefiles>> erstellen muss.>> Echt? Welche Arten von Eclipse-fremden Fremd-Projekten kann CooCox denn> importieren und dabei die notwendigen Compiler-Optionen, Pfade und> Defines vollautomatisch erkennen?
"das" -> - ich habe keinen Switch gefunden, damit der Compiler für
Includes das komplette Projektverzeichnis rekursiv durchsucht. Nach
Internet und Doku-Suche behelfe ich mir momentan durch das manuelle
Einstellen der einzelnen Suchpfade.
Coocox macht "das". Und ich glaube gefragt zu haben, ob jemand weiß, was
ich tun muss, damit Atollic "das" auch macht.
Marcus H. schrieb:> Coocox macht "das". Und ich glaube gefragt zu haben, ob jemand weiß, was> ich tun muss, damit Atollic "das" auch macht.
Naja, Du hast mein Posting zitiert, deshalb ging ich davon aus du
beziehst dich mit dem "das" auf das was ich geschrieben hatte.
Marcus H. schrieb:> "das" -> - ich habe keinen Switch gefunden, damit der Compiler für> Includes das komplette Projektverzeichnis rekursiv durchsucht.
Den müsstest du wenn schon im GCC suchen, den gibts da aber nicht
(unabhängig von der IDE), denn das wäre ja auch völlig bescheuert, das
gibt ein Chaos (man stelle sich vor, unter den 1000en Dateien heißen
zwei gleich).
Man gibt per -I (include-pfad) typischerweise pro Library einen Pfad an
(z.B. einen zur CMSIS, einen zur Standard Peripheral Library, einen zur
FatFS, ...) und wenn die library aus unterverzeichnissen besteht,
schreibt man die mit ins #include. Und wenn du wirklich 200 Libraries
hast, du also 200 -I -Flags rechtfertigen würden, solltest du über
pkg-config o.ä. nachdenken...
Dr. Sommer schrieb:> Marcus H. schrieb:>> "das" -> - ich habe keinen Switch gefunden, damit der Compiler für>> Includes das komplette Projektverzeichnis rekursiv durchsucht.> Den müsstest du wenn schon im GCC suchen, den gibts da aber nicht> (unabhängig von der IDE), denn das wäre ja auch völlig bescheuert, das> gibt ein Chaos (man stelle sich vor, unter den 1000en Dateien heißen> zwei gleich).> Man gibt per -I (include-pfad) typischerweise pro Library einen Pfad an> (z.B. einen zur CMSIS, einen zur Standard Peripheral Library, einen zur> FatFS, ...) und wenn die library aus unterverzeichnissen besteht,> schreibt man die mit ins #include. Und wenn du wirklich 200 Libraries> hast, du also 200 -I -Flags rechtfertigen würden, solltest du über> pkg-config o.ä. nachdenken...
Die doppelte Namensvergabe ist ein interessanter Punkt, aber bisher zum
Glück real noch nicht aufgetreten.
Ich sehe, dass es hier interessante Konfigurationsmöglichkeiten gibt.
Im Moment gebe ich die Hoffnung noch nicht auf, dass es ein einfaches
Verfahren gibt.
Ich war anfangs auch enttäuscht wg. der manuellen Include/Librarypfad
konfiguration. Immerhin gibt es mittlerweile die Buttons für den
Filedialog zur einfachen Auswahl, das war soweit ich weiss anfangs auch
nicht so. Und man kann die Einstellung per Cut&Paste in eine andere
Konfiguration mitnehmen, für Release und Debug muss man ja jeweils neue
Konfigurationen anlegen.
Für einfache Projekte oder wachsende Sachen ist das ok, aber ich finde
auch das es nicht schwer sein kann ein Verzeichniss nach includes/libs
zu durchsuchen und das Ergebnis als Baum mit Checkboxen anzuzeigen. Es
ist sogar ein Include-Browser (Navigate/Open Include Browser) vorhanden
der die verschachtelte Include Struktur im Workspace anzeigt, aber auch
da finde ich keine Option das in die Konfig zu übernehmen.
Auf Eclipse aufbauende IDE gibt es einige und alle haben ihre Vor- und
Nachteile.
Als Atollic TrueStudio Lite aufkam, war es durch die Möglichkeit Keil
µVision- Projekte zu portieren und (damals) ohne Codesize-Limit eine
echte Bereicherung für mich und Grund genug, mich dort einzuarbeiten.
Doch dann ist Atollic eingeknickt unter dem Druck der finanzstarken
Konkurenz.
Warum sollte ich wieder auf dies unsichere Pferd setzen?
(schon die Ausgabe als .hex war nicht ohne "Biegen und Brechen" möglich)
Irgentwann ist den Machern von Atollic ihr Traum von der eigenen
Karibikinsel wieder wichtiger als die User, die sie damit verprellt
haben ..
.. und ich fange erneut von vorne an.
Wie wäre es dann stattdessen für kommerzielle Sachen mit SES? Kommt
direkt von Segger und basiert anscheinend auf Rowley. Ich habe schon
damit gearbeitet und bin echt begeistert. Vor allem weil man da auch
Ansprechpartner hat wenns Probleme gibt. Die scheinen da echt mal Ahnung
von dem ganzen Kram zu haben, dieses "The Embedded Experts" ist bei
denen wohl nicht nur Marketing.
Die
http://www.rowley.co.uk/
Rowley-IDE habe ich auch als effizient in Erinnerung!
Segger und ihre µC eher als penetrant;
Guest schrieb:> Wie wäre es dann stattdessen für kommerzielle Sachen mit SES?
Ich brauche glücklicherweise keine "kommerzielle Sachen" mehr, ist
nurnoch Hobby ..
.. und da schaue ich, an den Nachwuchs denkend, auf opensource (ohne
das sich da Trittbrettfahrer eine goldene Nase verdienen möchten);
e-d schrieb:> Rowley-IDE habe ich auch als effizient in Erinnerung!> Segger und ihre µC eher als penetrant;
Häh? Was ist denn "Segger und ihre µC"??
Wäre mir neu das Segger Mikrocontroller produziert...davon abgesehen,
das es um SES ging ;-).
Michael K. schrieb:> Christian J. schrieb:>> EmBitz oder EmWin und Du bist glücklich!> Stellt sich dann gleich dieselbe Frage: was ist der Vorteil ggü. einer> selbst zusammengestellten Umgebung? Ist zwar ein gewisser Aufwand, es> gibt mittlerweile aber gute Tutorials dazu.
Du benennst genau den Vorteil. Die Umgebung ist bereits zusammengestellt
und aufeinander abgestimmt.
Und mit der Kaufversion hast Du auch Support dabei.
Ist aber sicherlich Geschmackssache. Nicht jeder möchte in die Tiefen
des einzelnen Plugins usw. einsteigen (selbst zusammenstellen).
e-d schrieb:> (schon die Ausgabe als .hex war nicht ohne "Biegen und Brechen" möglich)
Ich bin noch Stand 5.2.2. Da geht die Hex-Ausgabe noch ohne Biegen und
Brechen. Hat sich das geändert?
Heftig ist bei Atollic erstmal das einfach alles installiert wird und
damit >4GB auf der SSD ruhen. Davon ca. 1,5 GB in Support von (für mich)
exotischen Prozessorfamilien, das meisste davon sind unzählige XML
Registerbeschreibungen.
Immerhin scheint der Wettbewerb zu den freieren Lite Versionen zu führen
:-)
Steffen R. schrieb:> Du benennst genau den Vorteil. Die Umgebung ist bereits zusammengestellt> und aufeinander abgestimmt.
Du benennst genau den Nachteil: Es ist auf einander eingestellt, nicht
jedoch auf den Anwender.
e-d schrieb:> Die> http://www.rowley.co.uk/> Rowley-IDE habe ich auch als effizient in Erinnerung!> Segger und ihre µC eher als penetrant;
Das Segger Zeug läuft nur mit deren teueren J-Links........
Ich bin schon vor Jahren bei Rowley gelandet, da gibt es auch
für wenig Geld eine Version für nicht kommerzielle Nutzung zu
kaufen. Damit bin ich super zufrieden.
Dieses ganze andere Open source geraffel ist doch einfach wusel.
edgar S. schrieb:> Das Segger Zeug läuft nur mit deren teueren J-Links........
Ich nehme an mit Segger Zeug meinst du SES? embOS und die andere
Middleware hat mit einer Debug Probe erstmal nichts zu tun.
50,- Euro für einen J-Link EDU finde ich jetzt auch nicht teuer. Aber es
ging ja auch um kommerzielle Projekte, da ist die Arbeitszeit teuer als
der Preis für einen J-Link.
edgar S. schrieb:> Ich bin schon vor Jahren bei Rowley gelandet, da gibt es auch> für wenig Geld eine Version für nicht kommerzielle Nutzung zu> kaufen. Damit bin ich super zufrieden.>> Dieses ganze andere Open source geraffel ist doch einfach wusel.
FULL ACK! Ich verstehe auch nicht warum man sich diesen Bastelkram
antut.
edgar S. schrieb:> Ich bin schon vor Jahren bei Rowley gelandet, da gibt es auch> für wenig Geld eine Version für nicht kommerzielle Nutzung zu> kaufen. Damit bin ich super zufrieden.
Habe es mir gerade mal angeschaut.
Aaaaaaahhhhh! Schaut sehr gut aus. Schlank, schnell, könnte man
sich dran gewöhnen. Kein "nach hause telefonieren". Keine Bevormundung.
Für mich super-sinnvolle intuitive Bedienung. Keine trägen (Sekunden
dauernde Totzeiten) Kontext Menüs, schon fast ein Wunder bei den
heutigen überladenen IDEs.
Fehlt noch Support für den Atmel ICE, dann könnte man Atmel Studio
eventuell beiseite legen.
Guest schrieb:> FULL ACK! Ich verstehe auch nicht warum man sich diesen Bastelkram> antut.
Ja, vers
Guest schrieb:>>>> Dieses ganze andere Open source geraffel ist doch einfach wusel.>> FULL ACK! Ich verstehe auch nicht warum man sich diesen Bastelkram> antut.
Ja, verstehe auch nicht warum Rowley, Atollic, EmBlitz usw usw diesen
wuseligen Open Source Compiler GCC verwenden (lies: sich mit dessen
Federn schmücken und auch noch Geld dafür verlangen).
Bernd K. schrieb:> Steffen R. schrieb:>> Du benennst genau den Vorteil. Die Umgebung ist bereits zusammengestellt>> und aufeinander abgestimmt.>> Du benennst genau den Nachteil: Es ist auf einander eingestellt, nicht> jedoch auf den Anwender.
Für mich hat es bisher immer gepasst. Ich konnte bisher immer ohne
Zusatzaufwand loslegen. Insofern ist es für mich ein Vorteil.
Ich kann bei solchen IDEs auch reletiv einfach unseren Kunden helfen, wo
etwas zu finden ist. Dies ist bei individualisierten Zusammenstellungen
eher nicht der Fall.
Dr. Sommer schrieb:>>> Dieses ganze andere Open source geraffel ist doch einfach wusel.>> FULL ACK! Ich verstehe auch nicht warum man sich diesen Bastelkram>> antut.> Ja, verstehe auch nicht warum Rowley, Atollic, EmBlitz usw usw diesen> wuseligen Open Source Compiler GCC verwenden
… und warum der CTO von Segger mittlerweile sogar schon Bugreports
bei OpenOCD schreibt. ;-)
Dr. Sommer schrieb:> Ja, verstehe auch nicht warum Rowley, Atollic, EmBlitz usw usw diesen> wuseligen Open Source Compiler GCC verwenden (lies: sich mit dessen> Federn schmücken und auch noch Geld dafür verlangen).
Compiler != IDE
Hier hat keiner etwas gegen den GCC gesagt, aber eine IDE besteht aus
mehr als nur dem Compiler.
Genauso:
Kommerziell != Privat/Hobby
Da hat man ganz andere Anforderungen.
Jörg W. schrieb:> … und warum der CTO von Segger mittlerweile sogar schon Bugreports> bei OpenOCD schreibt. ;-)
Weil OpenOCD auch mit dem J-Link funktioniert!?
Es sehe das Segger sowas auch unterstützt eher positiv.
Guest schrieb:>> … und warum der CTO von Segger mittlerweile sogar schon Bugreports>> bei OpenOCD schreibt. ;-)>> Weil OpenOCD auch mit dem J-Link funktioniert!?
Wenn es so schlecht wäre, wie das oben behauptet wird, würden sie
sich aber gewiss nicht dafür interessieren. Schließlich haben sie
ja ihre eigene Softwarelösung für ihre Kunden.
Jörg W. schrieb:> Wenn es so schlecht wäre, wie das oben behauptet wird, würden sie> sich aber gewiss nicht dafür interessieren. Schließlich haben sie> ja ihre eigene Softwarelösung für ihre Kunden.
Äh...die Logik erschließt sich mir gerade nicht.
Segger benutzt ja nicht selber intern OpenOCD sondern sie sind natürlich
daran interessiert das der J-Link mit allem kompatibel ist. Es gibt halt
Kunden, die OpenOCD einsetzen möchten. Also wird dafür gesorgt, das es
auch damit problemlos funktioniert. Und dazu gehört auch die OpenOCD
Entwickler auf Probleme in Ihrer Software hinzuweisen.
Guest schrieb:> Äh...die Logik erschließt sich mir gerade nicht.
Mich piept einfach nur das permanente Gemecker über Opensource an.
Klar kann es Sinn haben, dass sich einer mit kommerziellem Interesse
(und dann gegen Geld) hinsetzt und eine Integrationsumgebung für
alles Mögliche zimmert. Aber das macht die zugrunde liegenden
Opensource-Bausteine deshalb nicht verdammenswürdig, sondern es ist
einfach eine auf diesen aufsetzende Zusatzleistung.
Ich war dennoch ziemlich erstaunt darüber, dass Segger trotz ihrer
eigenen Software noch so viel Interesse am parallelen Opensource-Projekt
haben.
Edit: Beitrag gelöscht wegen Verstoß gegen die Forenregeln.
Wenn du dich schon extra abmelden musst, um dich so herablassend zu
äußern, dann sagt das ziemlich viel über deine Persönlichkeit aus.
Aber zwei verschiedene Namen im gleichen Thread sind nach wie vor
nicht gestattet.
Jörg W. schrieb:> Mich piept einfach nur das permanente Gemecker über Opensource an.
Ich glaube nicht das hier die Qualität der Opensource angezweifelt
wurde. Eher das man sich den Vorteil von 'no limits' durch ein
zeitaufwändiges Puzzle erkauft. Und so habe ich das bezogen auf den
Einstieg mit ARM auch erlebt: bei den ersten günstigen ARM7TDMI musste
man zB mit Yagarto alles mühsam zusammensuchen, den OpenOCD
konfigurieren und erstmal passende USB Treiber finden (Parallel ist ja
schon lange ausgestorben). Dann hatte ich eine Rowley Testversion
installiert und damit lief es auf Anhieb.
Und das es heute viele Lite Version gibt und auch die Code/Debugsize
Grenzen fallen ist sicher dem Wettbewerb zu verdanken.
Atollic/Segger/Keil/NXP/CooCox liefern schon sehr komplette Pakete. Und
auch die Wizzards (die einige eher für Teufel halten) sind sehr
hilfreich, µC mit ARM Kern gibt es ja von zig Herstellen in Tausenden
Varianten und da ist das selberstricken von Linkerfiles und Startupcodes
für Einsteiger eher abschreckend.
Und das Atollic kurz vor der Embedded auf die Pauke haut ist sicher auch
kein Zufall...
> Klar kann es Sinn haben, dass sich einer mit kommerziellem Interesse> (und dann gegen Geld) hinsetzt und eine Integrationsumgebung für> alles Mögliche zimmert. Aber das macht die zugrunde liegenden> Opensource-Bausteine deshalb nicht verdammenswürdig, sondern es ist> einfach eine auf diesen aufsetzende Zusatzleistung.>
Man muss da wohl differnzieren. Bei z.B. Atollic würde ich dir da Recht
geben, ich würde auch nicht einsehen wieso man nicht direkt ein Eclipse
CDT benutzen kann. Bei Atollic sind bestimmt noch ein paar nette
Features dabei, aber da muss man schauen, ob man die braucht.
Bei den ganzen Segger Sachen z.B. sehe ich aber keine zugrunde liegende
Opensource-Bausteine, wenn man mal von GCC absieht.
> Ich war dennoch ziemlich erstaunt darüber, dass Segger trotz ihrer> eigenen Software noch so viel Interesse am parallelen Opensource-Projekt> haben.
Segger verdient das Geld (unter anderem) mit dem J-Link und nicht mit
der J-Link Software. Davon abgesehen sind die Hobbyleute von heute
vielleicht die Kunden von morgen ;-).
Guest schrieb:> aber eine IDE besteht aus> mehr als nur dem Compiler.> Genauso:> Kommerziell != Privat/Hobby> Da hat man ganz andere Anforderungen.
Die verfügbaren OpenSource IDEs für C und C++ (es gibt einige) lassen
eigentlich kaum noch Wünsche offen.
Bernd K. schrieb:> Die verfügbaren OpenSource IDEs für C und C++ (es gibt einige) lassen> eigentlich kaum noch Wünsche offen.
Naja, bei ARM ist es leider nicht ganz so schön einfach wie bspw. bei
AVR, wo man mit einem “-mmcu=atmega328” auf der Kommandozeile den
Compiler veranlassen kann, den passenden Startup-Code und Linkerscript
selbst zu finden. Da muss man schon etwas mehr beim Projekt mit
„beilegen“, je nach Hersteller. Da kocht leider jeder sein eigenes
Süppchen.
Ich kann schon verstehen, dass man das lieber vorkonfiguriert nehmen
möchte, wenn man es haben kann.
Bernd K. schrieb:> Die verfügbaren OpenSource IDEs für C und C++ (es gibt einige) lassen> eigentlich kaum noch Wünsche offen.
Dann haben wir unterschiedliche Wünsche ;-). Klar, das ist teilweise
schon echt gut geworden aber wenn es kommerzielle Projekte sind ist Zeit
einfach Geld. Was mache ich denn wenn es Probleme gibt, z.B. Fehler im
Compiler oder Debugger? Darauf warten das die Community das irgendwann
vielleicht mal fixt? Im kommerziellen Bereich gab es einen Zeitlang den
Trend Geld zu sparen und kostenlose IDEs einzusetzen. Irgendwann haben
die BWLer eingesehen, das das doch nicht günstiger ist und mittlerweile
merke ich das viele Firmen doch lieber wieder Geld für IDEs ausgeben
oder sogar "One Stop Solutions" von z.B. Segger bevorzugen. Hat einfach
den Vorteil das man alles von IDE/Compiler über Middleware bis hin zu
Debug Probe/Evalboard aus einer Hand bekommen kann. Da weißt man wenn
man ansprechen muss wenn was nicht funktioniert ;-).
Jojo S. schrieb:> den Vorteil von 'no limits' durch ein> zeitaufwändiges Puzzle erkauft
Das Puzzle machst Du aber nur einmal, danach kannst Du jahrelang damit
arbeiten. Manche haben sich den Beruf sogar zum Hobby gemacht (oder
umgekehrt) und können mit dem dabei über die Zeit hinweg angesammelten
Wissen das besagte Puzzle jederzeit blind binnen 5 Minuten auf nem neuen
Rechner frisch aufsetzen.
Wenn dieser einmalige initiale Zeitaufwand wegfällt dann kann die Arbeit
mit der maßgeschneiderten Umgebung sogar weitaus effizienter sein. Ich
setze sogar noch einen drauf und sage nicht nur "kann" sondern "wird"
denn mit dieser erworbenen Fähigkeit gehen auch mehr Verständnis für das
was man tut oder zu tun gedenkt einher.
Wenn jemand einen breiten Hintergrund in der Softwareentwicklung hat und
erst danach zum Microcontroller gekommen ist dann ist er bereits intim
vertraut mit alltäglichen Werkzeugen wie der Kommandozeile,
verschiedenen Compilern, verschiedenen Buildsystemen, Versionskontrolle,
etc., dann wird es ihn sehr seltsam anmuten wie die
Quereinsteiger-Gelegenheits-Programmierer aus der µC-Ecke an ihrer
Software "arbeiten" und wie sie für jedes läppische C-Progrämmchen erst
mal ne ganz spezielle andere IDE zu brauchen meinen, womöglich noch
welche die gleich vierstellige Summen kosten und im Grunde doch nichts
anderes machen als ein bisschen C-Code zu editieren und zu Debuggen.
Guest schrieb:> aber wenn es kommerzielle Projekte sind ist Zeit> einfach Geld.
Da macht man sich aber auch nicht von einer IDE abhängig.
Da schafft man sich seine Vorlage für die Infrastruktur, und lässt
hinterher "make" (oder eines seiner moderneren Pendants) drüber
laufen. Die paar investierten Stunden rentieren sich dann schnell.
> Was mache ich denn wenn es Probleme gibt, z.B. Fehler im> Compiler oder Debugger? Darauf warten das die Community das irgendwann> vielleicht mal fixt?
Das übliche Totschlagargument.
Zeig mir mal den Hersteller, bei dem du ohne Zahlung wirklich
erheblicher Beträge irgendeine Garantie bekommst, dass ein
gemeldeter Fehler innerhalb eines überschaubaren Zeitraums
repariert wird. Für ein paar Tausender bekommst du das nicht, da
darfst du auch nur genauso deine Bugreports schreiben wie bei einem
GCC, und kannst danach hoffen, dass er dem Hersteller wichtig genug
war, dass er wenigstens mit dem nächsten Release repariert ist.
Bernd K. schrieb:> dann wird es ihn sehr seltsam anmuten wie die> Quereinsteiger-Gelegenheits-Programmierer aus der µC-Ecke an ihrer> Software "arbeiten"
Absolut korrekt! Das geht dann damit weiter, dass Hochsprachen wie C++
und in der Software Entwicklung absolut übliche Paradigmen wie OOP,
große Entwicklungsumgebungen, oder gar makefiles verteufelt werden, und
Versionskontrolle als unnötiger Luxus deklariert. Da schüttelt der
"richtige" Programmierer nur den Kopf.
Wenn Microsoft einen C++ Compiler rausbringt erklärt die Community warum
der GCC oder Clang besser ist, wenn IAR oder Keil einen rausbringen
deklarieren alle den GCC als Schrott...
Jörg W. schrieb:> Zeig mir mal den Hersteller, bei dem du ohne Zahlung wirklich> erheblicher Beträge irgendeine Garantie bekommst, dass ein> gemeldeter Fehler innerhalb eines überschaubaren Zeitraums> repariert wird.
Kein Problem, ich habe schon Compiler Fehler z.B. im IAR EWRL78 gefunden
und die wurden kurzfristig gefixt. Will aber keine Werbung für IAR
machen ;-), zig Tausend Euro für einen IAR finde ich auch zu teuer.
Bernd K. schrieb:> Das Puzzle machst Du aber nur einmal, danach kannst Du jahrelang damit> arbeiten.
Schön wärs. Ich kann mir leider nicht aussuchen mit was ich arbeite
sondern ich muss so doof wie es sich anhört mit jedem Compiler/IDE
arbeiten, da meine Software auf so ziemlich alles portiert wird. Ich
zahle aber in der Regel auch nichts für IDE/Compiler.
Letzlich muss aber natürlich jeder selbst entscheiden mit welchem
Werkzeug er am besten arbeiten kann.
Guest schrieb:> Kein Problem, ich habe schon Compiler Fehler z.B. im IAR EWRL78 gefunden> und die wurden kurzfristig gefixt.
Nur eine Garantie darauf hast du eben nicht. Es häte genauso gut
ein Jahr dauern können.
Damit unterscheidet es sich aber nicht grundlegend von einem GCC. Auch
dort kann es dir passieren, dass du schon nach wenigen Tagen einen
Fix hast (wenn du denn gewillt bist, dir den Compiler selbst neu zu
bauen), aber es kann eben auch schon mal ein Jahr dauern.
Guest schrieb:> Kein Problem, ich habe schon Compiler Fehler z.B. im IAR EWRL78 gefunden
Das lässt sich aber auch vermeiden indem man keine fehlerhaften
Exoten-Compiler von kleinen Privatklitschen verwendet sondern was großes
gut abgehangenes und breit getestetes mit viel manpower dahinter wie z.
B. den gcc.
Bernd K. schrieb:> Guest schrieb:>> Kein Problem, ich habe schon Compiler Fehler z.B. im IAR EWRL78 gefunden>> Das lässt sich aber auch vermeiden indem man keine fehlerhaften> Exoten-Compiler von kleinen Privatklitschen verwendet sondern was großes> gut abgehangenes und breit getestetes mit viel manpower dahinter wie z.> B. den gcc.
Ok, das würde ja gegen IAR und für so etwas wie Segger SES sprechen ;-).
Auch wenn man einsehen sollte das IAR keine kleine Klitsche und auch
kein Exoten Compiler ist. Leider macht der immer noch besseren Code als
GCC.
Bernd K. schrieb:> Das lässt sich aber auch vermeiden indem man keine fehlerhaften> Exoten-Compiler von kleinen Privatklitschen verwendet
Ich bin wirklich der letzte, der nicht als erstes einen GCC (oder
Clang) in Betracht ziehen würde, und ich finde auch IARs Preise
völlig überzogen – aber gute Compiler bauen sie auf jeden Fall, da
würde ich keine Luft ranlassen. Das als „Exoten-Compiler einer
kleinen Privatklitsche“ zu diffamieren heißt, dass du entweder ganz
massiv trollst oder einfach keinen blassen Schimmer hast.
Auch im GCC finden sich regelmäßig Fehler, genau wie bei jeder anderen
Software solch Umfanges.
Guest schrieb:> Leider macht der immer noch besseren Code als GCC.
Kann der denn auch den aktuellsten C++ Standard so gut wie der GCC?
Microsoft z.B. schafft das ja nicht so wirklich, templates werden da zB
völlig standardunkonform hingefaket.
Dr. Sommer schrieb:> Kann der denn auch den aktuellsten C++ Standard so gut wie der GCC?
Es ist ein Compiler für Embedded Programming. Insofern ist das ihr
Hauptaugenmerk. Aber an Standards waren sie zumindest früher immer
gut dran, du bekommst mit der Lizenz den Sourcecode zu einer komplett
standardkonformen C99-Bibliothek mit dazu, die aus dem Hause von
P. J. Plaugher stammt, der meines Wissens selbst im C99-Kommittee
sitzt.
Jörg W. schrieb:>> Kann der denn auch den aktuellsten C++ Standard so gut wie der GCC?>> Es ist ein Compiler für Embedded Programming. Insofern ist das ihr> Hauptaugenmerk.
Was hat das eine mit dem anderen zu tun?
Bernd K. schrieb:> Was hat das eine mit dem anderen zu tun?
Das man als Embedded C++ (EC++) normalerweise nur eine Untermenge
des kompletten C++-Standards ansieht.
> templates werden da zB völlig standardunkonform hingefaket.
Leute die meines Wissens nach einen Codegenerator für ++ schreiben
können, sind ziemlich rar. Lebende Exemplare dürften fast an den Fingern
abgezählt werden können (vielleicht so um die 20) und da ist es ziemlich
unwahrscheinlich dass einer davon gerade einen neuen Job sucht. Soweit
ich gehört habe, musste sogar Microsoft diese Stelle längere Zeit
ausschreiben bis sich jemand gefunden hat ...
Im Übrigen hat man dem abgesetzen Code vom Microsoft C Compiler schon in
den Anfangszeiten von DOS (als es weder Windows noch ++ gegeben hat)
schon von weitem angesehen, daß der Ersteller keinerlei Ahnung von
Compilerbau gehabt hat. Wenn ein kommerzielles Paket besser als der GCC
optimiert ist das natürlich legitim. Dafür bezahlen dann die Firmen z.
Bsp. aus dem Automotive Umfeld welche ein Projekt in Zeit gegen Null
erstellen wollen und dann noch 0,5 Cent für einen billigeren Controller
mit kleinerem Flash in Millionen Stückzahlen einsparen wollen. Bei
meinen Stückzahlen ist mir das als Frickler egal und wenn ich kleinen
Code haben möchte gibt es ziemlich große Unterschiede zwischen zwei
C-Programmen welche das Gleiche tun. Paradebeispiele sind die ST-Libs
für den ST32 und den ST8. Als völlig unschlagbare Optimierung gibt es
nach wie vor die Möglichkeit (auch mit GCC) die Quellen in Assembler zu
erstellen ...
Jörg W. schrieb:> Bernd K. schrieb:>> Was hat das eine mit dem anderen zu tun?>> Das man als Embedded C++ (EC++) normalerweise nur eine Untermenge> des kompletten C++-Standards ansieht.
Das "richtige" EC++ ist so tot, toter geht's nicht
http://www.caravan.net/ec2plus/ letztes Update 2002... Keine Templates,
keine Namespaces, keine Mehrfachvererbung, keine STL, keine Libs für
wchar_t oder long double, keine Exceptions, keine RTTI. Über vieles
ließe sich streiten über Templates und Namespaces nicht.
Und was macht IAR? C++ Standard 2003 und Extended Embedded C++ (EC++ mit
Templates, Namespaces, Mehrfachvererbung)
Genauso ist es und genau deswegen benutze ich derzeit emBITZ. Es fehlt
allerdings an einer ordentlichen Unterstützung für M7 Controller, daher
suche ich nach einer GCC-Alternativen.
Eclipse mag für viele Suchende eine Lösung sein, ich jedoch befinde sie
für einfach viel zu umständlich und unübersichtlich. Ich möchte mich
nicht mehr als notwendig mit der Zusammenstellung der IDE befassen
müssen denn ich möchte mich auf die Software-Entwicklung der Controller
zu beschränken.
Alle bisher viele IDE's wie Atollic TrueStudio, System-Workbench for
STM, CoocoxIDE,AC6 angesehen und alle basieren auf Eclipse und leider
haben sie alle (wie soll's auch anders sein) die gleichen Schwächen.
Ohne dass man sich erst einmal länger mit Eclipse und den Plug-in's
beschäftigen muss, nutzbar. Diese Zeit möchte ich mir sparen, solange es
nicht nötig ist.
Warum einige Anbieter wie Atollic oder Andere, Geld für open-Source
Produkte haben wollen, ist mir schleierhaft. Support muss bezahlt werden
- niemand macht dies kostenlos. GNU-Komponenten wie der GCC-Compiler,
Debugger und Linker, samt Libraries usw. bedürfen keines weiteres
Supports.
Juppecl schrieb:> Warum einige Anbieter wie Atollic oder Andere, Geld für open-Source> Produkte haben wollen, ist mir schleierhaft.
Ich könnte mir gut vorstellen, dass diese Firmen einen Teil ihrer
Einnahem an diese Open-Source-Projekte weiterleiten.
"Ich könnte mir gut vorstellen, dass diese Firmen einen Teil ihrer
Einnahem an diese Open-Source-Projekte weiterleiten."
Das glaube ich wohl ehr nicht.