Hallo, der Titel hört sich etwas hart an aber für neue Projekte im Bereich IoT Steuerungen mit Sensoren, würde ich gerne auf die Atmel SAM Plattform wechseln. Bei älteren Projekten hat der STM32F427 gut gedient und mit Keil war die Programmierung auch recht flott zu meistern. Jedoch wächst unser Team und Keil (Traum Debugger) ist sehr teuer. Die Eclipse Toolchain mit STM32 CUBE Mx ist ganz nett nur hat die neue Library (HAL) von ST sehr viele Bugs und Fehler. Dies stellten wir bei unserem letzten Projekt mit dem STM32F411CE schnell fest - die alte Std. Periph. Lib mit dem F427 funzte super. Insgesammt saßen wir 2,5 Wochen dran die Library zu fixen - schlußendlich bekamen wir vom ST support keine geeigneten workarounds mehr... Eclipse mit openOCD hat gerade wenn man kommerziell agieren möchte ihre Tücken (neue MCU's werden spät integriert, hoher installationsaufwand, umständlich mit includes viele Fehlerquellen Debugger Probleme). ...nun gut, jetzt die eigentliche Frage: Das Atmel Studio ist eine sehr nette IDE und vor allem kostenlos. Ich würde gerne ein bissl die Erfahrungen und Tipps hören hinsichtlich Bibliothek, Code Interkompatiblität SAMx <-> SAMy, Anschaffung von hilfreichen Tools, FreeRTOS Support, CodeCoverage, Trace .... Was sind so eure wichtigsten Erkenntnisse / Tipps , was sollte man auf jeden Fall meiden? VG
:
Bearbeitet durch User
hallo, willst du wegen der tool-kette auf SAM umsteigen? davon kann ich nur abraten. das atmel studio ist ein einziger krampf! wenn du jemals mit einer professionellen ide gearbeitet hast dann greifst du das atmel studio nicht mehr freiwillig an. wenn ich dein popsting richtig verstanden habe arbeitest du im kommerziellen bereich. in dem fall rechnet sich eine weitere keil lizenz (ev. mal eine floating lizenz anfragen) aufgrund der einarbeitungszeit in das atmel studio und die beim arbeiten mit dem studio verloren gegangene zeit in jedem fall. gruss gerhard
Wenn Open OCD das Problem ist hast du dir http://gnuarmeclipse.livius.net/blog/ angesehen? Gerade diese Schwachstelle auszumerzen habe die sich ja auf die Fahnen geschrieben. Was die HAL von ST angeht. Glaube ich nicht das Atmel nicht die gleichen Probleme hat. Zur Not geht man an der HAL vorbei bzw. macht seine Eigene. Aber auch da hat man immer wieder das Problem das irgend eine Spezielle Konfiguration nicht abgebildet ist oder fehlerhaft. Die Zeit musst du mit ein Planen im Projekt.
Ersan G. schrieb: > nur hat die neue > Library (HAL) von ST sehr viele Bugs und Fehler. Und Du träumst wirklich davon, daß Dir ein anderer Hersteller für umme eine bessere bugfreie Lib bereitstellt. Wenn Du ein HAL benutzen willst, aber es nicht selber programmieren, dann mußt Du dafür löhnen (Keil).
Wenn die Kosten zu hoch sind, vielleicht mal mit dem Keil Vertrieb reden? Da Lizenzen keine Produktionsgüter sind, geht da meistens was. Ich kenne Firmen die geben an Großkunden 80% Rabatt auf die Listenpreise.
Ersan G. schrieb: > Das Atmel Studio ist eine sehr nette IDE ich habe coide, Lpcxpresso und avr-Studio 6.xx relativ unvoreingenommen ausprobiert, weil mir der Hersteller der mcu im Prinzip egal ist. Meine Reihenfolge wäre 1. Lpcxpresso => super Debugger + ausgereift, 2. Coide => im Vergleich zu Lpcxpresso nur abgespecktes eclipse. 3. Niemals avr-Studio, da im Vergleich zu 1+2 instabil und viel zu langsam.
Ersan G. schrieb: > Die Eclipse Toolchain mit STM32 CUBE Mx ist ganz nett nur hat die neue > Library (HAL) von ST sehr viele Bugs und Fehler. > Dies stellten wir bei unserem letzten Projekt mit dem STM32F411CE > schnell fest - die alte Std. Periph. Lib mit dem F427 funzte super. > Insgesammt saßen wir 2,5 Wochen dran die Library zu fixen - > schlußendlich bekamen wir vom ST support keine geeigneten workarounds > mehr... Naja, das Atmel Studio hat auch so seine Problemchen (neben allgemein mieser Performance). Wir haben da einige "kreative Hacks" im Einsatz. ASF scheint mir ebenso nicht das Gelbe vom Ei zu sein und die einem aufgezwungene "Cloud" Atmel Gallery nervt. Über den lahmen JTAGICE ärgere ich mich dauernd, das Flashen von ca. 100 KB dauert eine Ewigkeit (mit ST-Link/V2 und STM32 flutscht es dagegen). Wir nutzen allerdings von Atmel hauptsächlich XMEGA. Wenn ihr keine Lust auf OpenOCD habt, wie wäre es mit Segger J-Link o.ä.? Nicht unbedingt billig, dafür gibt's dann aber sehr gute Softwareunterstützung. Und ganz allgemein: Bei den anderen sieht das Gras natürlich immer grüner aus.
ist das Atmel Studio beim Xmega wirklich besser als Mikroe?
Ersan G. schrieb: > Eclipse mit openOCD hat gerade wenn man kommerziell agieren möchte ihre > Tücken (neue MCU's werden spät integriert, hoher installationsaufwand, > umständlich mit includes viele Fehlerquellen Debugger Probleme). Aber wären nicht da gerade Anwender mit kommerziellen Interesse gefordert, die Integration neuer CPU zu unterstützen bzw. anzugehen?
Ich benutze Atmel Studio seit mehreren Jahren und hatte noch nie Probleme, die ich nicht in weniger als 15min lösen könnte. In Kombination mit dem J-Link bin ich hoch zufrieden (7TDMI, Cortex-M3, M4 und M0+).
Mir tut das nicht weh, im Gegenteil, wir bauen ein neues Portfolio mit diesem Prozessor auf. Und auf diese Aussage kommt mir eigentlich an: >Ich benutze Atmel Studio seit mehreren Jahren und hatte noch nie >Probleme, die ich nicht in weniger als 15min lösen könnte. Das wäre dann auf jeden Fall einen Versuch wert.
:
Bearbeitet durch User
Um meine Aussage zu präzisieren: Ich habe mich vor allem immer gefreut, dass Studio + J-Link immer (für meine Fälle!!!, das muss nicht generell gelten...) out of the box funktioniert hat.
Ersan G. schrieb: > gerade wenn man kommerziell agieren möchte Ah so. Du agierst kommerziell, hast Zuwachs mit jungen Programmmierern und kein Geld, denen eine Keil-Lizenz auszugeben. Aber jeweils eine IDE scheint ihr pro Arbeitsplatz zu benötigen, denn ihr wißt nicht, was ihr schreibt und müßt es debuggen - und das nach Jahren des kommerziellen Agierens mit dem STM32F427, wo man eigentlich längst sein eigenes, gut ausgetestetes Portfolio haben sollte, weil ihr eben auf sowas wie die ST-Lib und jetzt deren Nachfolger vertraut - aha. Mein Rat wäre, bei dem ST zu bleiben und endlich ein eigenes Portfolio an selbst verfaßten Treibern, HAL und so weiter auf die Beine zu stellen. Weiters würde ich mal anregen, die jungen Leute zu etwas Selbstdisziplin zu erziehen. Das geht beispielsweise so, daß der vorhandene Keil auf dem Server installiert ist und von dort aus NUR die eigentlichen Tools (Compiler usw.) aufrufbar sind - zwar von jedem Mitarbeiter, aber nur hintereinander. Einen ordentlichen Editor für jeden Hansel werdet ihr ja wohl auftreiben können. Was bleibt, wäre ein Programmer auf Bootladerbasis an jedem Arbeitsplatz (kostet nix) - und eben die Forderung, den eigenen Grips zu schulen, anstatt sich nur auf den Debugger zu stützen. Also denken lernen. Früher hieß das Hinkriegen per Debugger "bananasoft" (reift beim Kunden). Ja - ich weiß, sowas gilt heutzutage nicht mehr als schick, aber wer als Programmierer damit nicht klarkommt, ist noch kein richtiger Programmierer. Aber besser so als garnicht, wenn es um die Firmenfinanzen derart eng bestellt ist. W.S.
W.S. schrieb: > und eben die Forderung, den eigenen Grips zu > schulen, anstatt sich nur auf den Debugger zu stützen. Also denken > lernen. Das heißt also, daß du ein Programm schreibst, compilierst das einmal und es läuft immer sofort. Ein Debugger ist also was für Weicheier, ja? > Früher hieß das Hinkriegen per Debugger "bananasoft" (reift beim > Kunden). Früher hat man also den Kunden einen Debugger mitgegeben? Ich muß schon sagen, du hast recht komische Ansichten. Jeder Programmierer wird dir bescheinigen können, daß ein Debugger Gold wert ist. Weil eben nicht jedes Programm sofort auf Anhieb läuft.
npn schrieb: > Ich muß schon sagen, du hast recht komische Ansichten. Jeder > Programmierer wird dir bescheinigen können, daß ein Debugger Gold wert > ist. Weil eben nicht jedes Programm sofort auf Anhieb läuft. Jeder Softwareentwickler wird dir bescheinigen, das ein Debugger nice to have ist. Überlebenswichtig sind die richtigen Konzepte. Wenn es bei professionellen Programmen in Richtung race conditions und Nebenläufigkeit geht, ist der Debugger-Addicted-Programmer sowieso verloren.
W.S. schrieb: > Ersan G. schrieb: >> gerade wenn man kommerziell agieren möchte > > Ah so. > > Du agierst kommerziell, hast Zuwachs mit jungen Programmmierern und kein > Geld, denen eine Keil-Lizenz auszugeben. Noch nichts von Startup's gehört? Jungen Unternehmen? Die nicht gerade von Anfang an mit einem Sofware Budget von 100.000€ entstanden sind? Ich glaube du hast sehr dunkele Scheuklappen auf. Immer gleich beleidigen das ist so typisch... > Aber jeweils eine IDE scheint ihr pro Arbeitsplatz zu benötigen, denn > ihr wißt nicht, was ihr schreibt und müßt es debuggen - und das nach > Jahren des kommerziellen Agierens mit dem STM32F427, wo man eigentlich > längst sein eigenes, gut ausgetestetes Portfolio haben sollte, weil ihr > eben auf sowas wie die ST-Lib und jetzt deren Nachfolger vertraut - aha. Wissensportfolio bis F427 und jetzt für neue Produkte mal eine andere Plattform ausprobieren. Was ist daran schlimm? Ich bin doch kein Siemens der 30 Jahre lang eine Plattform nutzt. Wir sind ein junges dynamisches, flexibles Startup. > Mein Rat wäre, bei dem ST zu bleiben und endlich ein eigenes Portfolio > an selbst verfaßten Treibern, HAL und so weiter auf die Beine zu > stellen. Haben wir für den F427 aber der F411 ist einfach eine Plattform mit zu vielen Fehlern. -> hier mal eine Interessante Story, ich scheine ja nicht der einzige zu sein: http://www.eevblog.com/forum/microcontrollers/st's-(stm32cube)-software-ecosystem-is-terrible-how-can-we-fix-it/ > Weiters würde ich mal anregen, die jungen Leute zu etwas Selbstdisziplin > zu erziehen. Das geht beispielsweise so, daß der vorhandene Keil auf dem > Server installiert ist und von dort aus NUR die eigentlichen Tools > (Compiler usw.) aufrufbar sind - zwar von jedem Mitarbeiter, aber nur > hintereinander. > Einen ordentlichen Editor für jeden Hansel werdet ihr ja wohl auftreiben > können. Was bleibt, wäre ein Programmer auf Bootladerbasis an jedem > Arbeitsplatz (kostet nix) - und eben die Forderung, den eigenen Grips zu > schulen, anstatt sich nur auf den Debugger zu stützen. Also denken > lernen. Früher hieß das Hinkriegen per Debugger "bananasoft" (reift beim > Kunden). sequentielles arbeiten ? Aha ok! Jeder coded und dann nacheinander Testen... Du beschreibst einen Workflow der in meinen Ohren sehr sehr ineffizient klingt. Bin ich froh das wir unseren kreativen Spielraum haben. > Ja - ich weiß, sowas gilt heutzutage nicht mehr als schick, aber wer als > Programmierer damit nicht klarkommt, ist noch kein richtiger > Programmierer. Aber besser so als garnicht, wenn es um die > Firmenfinanzen derart eng bestellt ist. > > W.S. sagt dir "slack" etwas?
gerhard schrieb: > davon kann ich nur abraten. > das atmel studio ist ein einziger krampf! > wenn du jemals mit einer professionellen ide gearbeitet hast dann > greifst du das atmel studio nicht mehr freiwillig an. Wg. der kostenlosen IDE von Atmel hatte ich für ein neues privates Projekt als Grundlage ein SAMD21 Xplained PRO Entwicklungskit ausgesucht - den Versuch mit der Atmel IDE hab' ich nach einer Stunde abgebrochen, weil mein Core2Duo Laptop mit 4GB Speicher und 32 Bit Betriebssystem damit hoffnungslos überfordert war. Ohne i7-Prozessor, 64bit Betriebssystem und 8GB Speicher würde ich von dem Atmel Studio auf jeden Fall die Finger lassen (wobei mich nicht wundern würde, wenn es sich dann dennoch als kompletter Reinfall herausstellen würde - wenn man zum Ausführen einer IDE einen derart ausgestatteten PC benötigt, kann dann die IDE brauchbar programmiert sein?). Der SAMD21 ärgert mich nun auch schon seit zwei Tage, mir gelingt es nicht, die GPIOs vom EXT2-Header einzulesen (Beitrag "SAMD21 Xplained pro / Eingänge lesen")
:
Bearbeitet durch User
@ U.G. L. (dlchnr) >- den Versuch mit der Atmel IDE hab' ich nach einer Stunde abgebrochen, >weil mein Core2Duo Laptop mit 4GB Speicher und 32 Bit Betriebssystem >damit hoffnungslos überfordert war. Ohne i7-Prozessor, 64bit >Betriebssystem und 8GB Speicher würde ich von dem Atmel Studio auf jeden >Fall die Finger lassen (wobei mich nicht wundern würde, wenn es sich >dann dennoch als kompletter Reinfall herausstellen würde - wenn man zum >Ausführen einer IDE einen derart ausgestatteten PC benötigt, kann dann >die IDE brauchbar programmiert sein?). Das ist wohl leider wahr. Ich hab noch nie so eine lahmarschige IDE gesehen, mit Online Rechtschreibkorrektur! (Muss ich mal abschalten) Such mal im Forum nach Atmelstudio 6, da wird dir schlecht! (Ich muss es halt für ein Xmega-Projekt nutzen, naja, ich werd's überleben)
Ersan G. schrieb: > Haben wir für den F427 aber der F411 ist einfach eine Plattform mit zu > vielen Fehlern. -> hier mal eine Interessante Story, ich scheine ja > nicht der einzige zu sein: > http://www.eevblog.com/forum/microcontrollers/st's-(stm32cube)-software-ecosystem-is-terrible-how-can-we-fix-it/ Ich frag mich gerade was ich dann falsch mache, ich hatte bisher kaum Probleme mit der HAL. UART, SPI, I2C, Timer in verschiedenen Konfigurationen, DMA, RTC, power management, RCC usw. lief bei mir alles recht problemlos und straight forward. Die Dokumentation ist allerdings Mist und die Beispiele könnten mehr sein. Sorgen mache ich mir aber höchstens wegen des Bloats.
Ersan G. schrieb: > Haben wir für den F427 aber der F411 ist einfach eine Plattform mit zu > vielen Fehlern. -> hier mal eine Interessante Story, ich scheine ja > nicht der einzige zu sein: > http://www.eevblog.com/forum/microcontrollers/st's-(stm32cube)-software-ecosystem-is-terrible-how-can-we-fix-it/ Interessant fand ich ja die Probleme mit IIC beim STM. Damit hatte ich auch viel zu viel Zeit vertüddelt, bis ich mir die paar Routinen in Software geschrieben habe. Ich dachte, ich wäre zu blöd, aber es beruhigt mich, daß es auch bei Anderen nicht klappt ;-) W.S. schwört auf NXP. Vielleicht wäre das eine Option.
> Ich frag mich gerade was ich dann falsch mache, ich hatte bisher kaum > Probleme mit der HAL. UART, SPI, I2C, Timer in verschiedenen > Konfigurationen, DMA, RTC, power management, RCC usw. lief bei mir alles > recht problemlos und straight forward. Die Dokumentation ist allerdings > Mist und die Beispiele könnten mehr sein. Sorgen mache ich mir aber > höchstens wegen des Bloats. Mit Freertos? Du kannst ja mal ein Beispiel Projekt der Community spenden.!
Ersan G. schrieb: > Mit Freertos? > > Du kannst ja mal ein Beispiel Projekt der Community spenden.! Teilweise. Was fehlt dir denn an FreeRTOS-Integration? Wenn man die Peripherie strukturiert nutzt, braucht man da doch eh nichts Besonderes, höchstens etwas Locking an einigen Stellen. Ich habe leider nicht die Rechte am Code, um etwas einfach so zu veröffentlichen.
Ja das Problem sind Treiber wie bspw. SPI, I2C, USART alle samt DMA die nicht direct vom Cube aus für FreeRTOS optimiert/geeignet sind. Cube wirft die Codefragmente einfach rein und erhofft sich, das der User selbstverständlich die FreeRTOS integration durchführt. FreeRTOS an sich selbst ist auch nicht vollständig im Cube implementiert. Und in den Release Notes steht überhaupt nichts von fehlenden Parametern drin. ... dürft für ST. Mit NXP hab ich mich noch nich wirklich auseinandergesetzt. Wir haben in einem Projekt einen LPC11C24 im Einsatz, das hat eigentlich wunderbar geklappt. Naja welcome to the embedded World. Kompromisse über Kompromisse.
Ersan G. schrieb: > Ja das Problem sind Treiber wie bspw. SPI, I2C, USART alle samt > DMA die > nicht direct vom Cube aus für FreeRTOS optimiert/geeignet sind. > Cube wirft die Codefragmente einfach rein und erhofft sich, das der User > selbstverständlich die FreeRTOS integration durchführt. Versteh nicht ganz was du meinst, aber sowas wie CubeMX würde ich mir freiwillig auch nicht antun. Code Generation, brr. > FreeRTOS an sich selbst ist auch nicht vollständig im Cube > implementiert. Was verstehst du denn konkret darunter?
Hallo, im Moment kann ich nur die IAR IDE und das Atmel Studio vergleichen. Hier macht das Atmel Studio die viel bessere Figur. Ich arbeite mit beiden IDE's wirklich intensiv. In Bezug auf Navigation durch den Code und Refaktorierung ist Atmel Klasse. Debugen funktioniert auch hervorragend. Die Periperie der Atmel SAM’s sind aus meiner Sicht wesentlich gradliniger als bei ST. Das Zeigt sich auch bei der DMA Anbindung. mfg
Keine Ahnung was hier anscheinend 90% der Leute falsch machen. Atmel Studio läuft wenn es gestartet ist flüssig. Und das auf jedem halbsweg aktuellen PC hier. i5 ist gar kein Problem. Und die IDE, die auf Visual Studio aufbaut, ist der von Keil in jedem Fall vorzuziehen.
@ avr (Gast) >Keine Ahnung was hier anscheinend 90% der Leute falsch machen. Atmel >Studio läuft wenn es gestartet ist flüssig. Ach? Wenn man die Projektoptionen öffnet, passsiert teilweise 30s NICHTS! Das Fenster sit halb aufgebaut! Auch beim Durchblättern der verschiedenen Optionsfenster ist ähnlich! Das Navigieren im Textfenster ist zäh. Das macht u.a. die automatische Ersetzung/Stichwortvorgabe und die Online Rechtschreibprüfung. Schön ist was anderes.
Das Kompilieren mit dem AVR Studio ist auch recht zäh. Parallelisierung klappt nicht richtig. Es gibt nur eine Option, die ein "make -j" macht, aber die Anzahl der parallel laufenden Prozesse sollte begrenzt werden. So kommt es dann zu Thrashing u.ä. :( Darüber hinaus hat diese Option Bugs und Parallelisierung wird irgendwie oft gar nicht genutzt.
drama schrieb: > eine Option, die ein "make -j" macht, > aber die Anzahl der parallel laufenden Prozesse sollte begrenzt werden. > So kommt es dann zu Thrashing u.ä. :( Darüber hinaus hat diese Option > Bugs und Parallelisierung wird irgendwie oft gar nicht genutzt. Das scheint unter Windows sowieso nicht trivial zu sein, zumindest nicht mit den paar Versionen von make.exe die ich schon getestet habe. Anscheinend ist es für make unter Windows nicht ohne weiteres möglich festzustellen wieviele Prozesse noch laufen, also startet es alle auf einmal. Das kann gut gehen bei einfachen Sachen aber wenn Targets von anderen Targets abhängen und make denkt das erste ist schon fertig und fängt das nächste an das davon abhängt dann knallts entweder (wenn vorher clean war) oder noch schlimmer es baut das abhängige Target mit ner alten Version einer Vorbedingung, kein direkter Fehler tritt auf aber das Ergebnis ist Glückssache :-(
Bernd K. schrieb: > Das kann gut gehen bei einfachen Sachen aber wenn Targets von > anderen Targets abhängen und make denkt das erste ist schon fertig und > fängt das nächste an das davon abhängt dann knallts entweder (wenn > vorher clean war) oder noch schlimmer es baut das abhängige Target mit > ner alten Version einer Vorbedingung, kein direkter Fehler tritt auf > aber das Ergebnis ist Glückssache :-( Wenn du die Abhängigkeiten korrekt verwaltest, passiert sowas nicht, unabhängig von Parallelisierung.
drama schrieb: > Bernd K. schrieb: >> Das kann gut gehen bei einfachen Sachen aber wenn Targets von >> anderen Targets abhängen und make denkt das erste ist schon fertig und >> fängt das nächste an das davon abhängt dann knallts entweder (wenn >> vorher clean war) oder noch schlimmer es baut das abhängige Target mit >> ner alten Version einer Vorbedingung, kein direkter Fehler tritt auf >> aber das Ergebnis ist Glückssache :-( > > Wenn du die Abhängigkeiten korrekt verwaltest, passiert sowas nicht, > unabhängig von Parallelisierung. eben doch. lies es nochmal!
Also bei mir läuft das Atmel Studio unter Parallels auf einem MacPro mit dem AVR ONE und SDK600 sowie Atmel ICE für SAM's ohne irgendwelche Performance Probleme. Das in Sytem Debugen ist ein Traum. Ich kann dieses ganze Gerede über "langsam" und schlechte Performance nicht nachvollziehen.
Habs jetzt getestet und es läuft auch bei mir sehr flott (Version 6.2)
Hab einen 3j alten Dell latitude Windows 7 und auch bei mir läuft es flüssig. Version 6.2 ist auf alle Fälle vorzuziehen. Die riesige ASF Example Bibliothek War das einzige was in früheren Versionen beim Öffnen neuer Projekte zu Verzögerungen führte. Trotzdem gibt es unnötigen Ballast wie die Rechtschreibprüfung aber auch eine sehr gute App note die beschreibt wie man was tunem kann. Man kann gespannt sein auf as7 auf der embedded wurde ein Vorgeschmack gezeigt. Es soll die neueste Shell verwendet werden und auch einen schlanken installer bei dem man auswählen kann was überhaupt installiert werden soll.
Bei mir läuft es auch zufriedenstellend schnell auf einem Core2Duo-Laptop. Der Startvorgang dauert, aber danach gibt es keine Probleme mit der Geschwindigkeit. (Version 6.2)
avr schrieb: > Keine Ahnung was hier anscheinend 90% der Leute falsch machen. 64bit OS? Speicherausbau?
Thomas Holmes schrieb: > Ich kann > dieses ganze Gerede über "langsam" und schlechte Performance nicht > nachvollziehen. 64bit OS? Speicherausbau? Prozessor?
Ersan schrieb: > Habs jetzt getestet und es läuft auch bei mir sehr flott 64bit OS? Speicherausbau? Prozessor?
Stefan schrieb: > Hab einen 3j alten Dell latitude Windows 7 und auch bei mir läuft es > flüssig. 64bit OS? Speicherausbau? Prozessor?
Stefan schrieb: > Hab einen 3j alten Dell latitude Windows 7 und auch bei mir läuft es > flüssig. 64bit OS? Speicherausbau? Prozessor?
:
Bearbeitet durch User
http://www.atmel.com/Images/AStudio6_2sp2_1563-readme.pdf von http://www.atmel.com/tools/atmelstudio.aspx Release Notes enthält auch Tipps für schwache Rechner. Keine Ahnung ob dies hilft. Zeigt aber die Stellen auf, die lt. Atmel bremsen.
soll ich als swd debugger den j-link holen oder den sam-swd ?
Ersan schrieb: > I7 (2013), 8gb ram, win 8.1 x64 > > Und hör auf zu spammen. Solche Angaben gehören nun mal dazu, wenn man die gemachten Aussagen sinnvoll einordnen möchte - wenn's mit einem "I7 (2013), 8gb ram, win 8.1 x64" nicht mal "flott" liefe, gäb's die Diskussion ja wohl erst gar 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.