Kennt sich jemand mit Atmel Studio aus?

[video6]

Ich frage für einen Bekannten der damit anfangen will oder muss.
Ich habe davon überhaupt kein Plan.

[Fritzler]

Atmel Studio wird bald aussterben, wenn du dir unbedingt eine Hersteller IDE antuen willst, dann wär das jetzt MPLAB.
MPLAB kann seit neustem (wegen der Atmel Übernahme) jetzt auch AVR.

[lüsterklemme2000]

Muss dein Bekannter denn unbedingt die Software verwenden? Denn von Atmel Studio würde ich auch abraten.
Eine gute Alternative wäre z.B. WinAVR als Editor (Oder gerne auch was mit Autovervollständigung) und Kompiler und zum Brennen dann z.B. AVRDudess.
Damit ist man in der Programmwahl auch bei späteren Umstellungen flexibler.

[Fritzler]

WinAVR is leider tot, seit 2010 gibts keine neue Version.

[lüsterklemme2000]

Das stimmt, wobei man ja einfach die AVR-GCC von der aktuellen Atmel Studio Version in WinAVR reinziehen kann, sodass immerhin der Compiler wieder auf einem recht neuen Stand ist.

[Fritzler]

Dann haste aber immernochned die neuen Header für die neuen AVRs und die klingen ja schon recht interessant.
Das artet dann zu nem sehr großen Gefummel aus die auchnoch umzuziehen.
Weiterhin ist das 2010er Programmers Notepad auch sehr in die Jahre gekommen.
Am Ende bauste dir WinAVR also quasi nochmal selber zusammen

Oder gleich ARM nehmen, bei den AVRs stimmt die Preis/Leistung einfach nimmer.
Debuggen ist ach nen Krampf, bei ARM wird einem das hinterhergeworfen.

[video6]

Ok ich geb ihm mal den Link zum Forum vielleicht meldet er sich sogar noch an
Was er genau machen will weiß ich ja auch nicht.
Er fängt an zu basteln und will auch verstehen was er macht.

[TheOsram]

Guten Tag an das Team der gepflegten Frickellei.

Ich bin der Bekannte, für den der Initiator des Threats diese Frage gestellt hat.
Elektrotechnik und Elektronik, zum Teil auch Frickelei, sind Hobby seit Kindertagen und mittlerweile auch Bestandteil eines Fernstudiums.
Ich folge dieser Seite schon sehr lange ca. 2012 oder so. Tinys und Megas habe ich bisher immer mit BASCOM bespaßt, das es dem VBA, das ich dienstlich nutze sehr ähnelt.
Ich möchte jetzt aber C lernen und die Tinys, Megas und Arduinos zukünftig damit unterhalten.

Ich habe das AtmelStudio7 heruntergeladen und die Arduino IDE dazugepackt. Sah am Anfang sehr alles sehr durchdacht und komfortabel aus.
Leider kam es schon beim simplen Ansteuern eines LCD durch einen Arduino NANO zu einer Fehlermeldung aufgrund von fehlenden Libraries.
Vieles ist mir aufgrund von noch fehlenden C-Kenntnissen noch nicht klar (Dateistrukturen, etc.).
Mit Arduino Sketch hab ich "Hallo Welt!" auf einem LCD mittlerweile hinbekommen, aber die Oberfläche bietet keine Syntax-Hilfe.

Welchen Editor, Kompiler und IDE würdet Ihr einem Neuling für C empfehlen?

Viele Gruße

[Matt]

Editor: Notepad++
Complier: AVR-GCC (kommandozeile- Eingabe, reicht mir bisher aus)

Dass du früher schonmal erfolgreich mit µC befasst, mit andere Sprache. Das macht Umstieg zu C-Code nicht schwerer.
Bis vor ca 3 J könnte ich nichtmal C-Code schreiben.

HD44780-Library für C Code kann ich nur der von P.Fleury * empfehlen. Sonst ist meiste Library total überlagert, dass ich aufhöre Library aus Web einzubinden und selber Library schreibe.


* http://homepage.hispeed.ch/peterfleury/ ... tware.html

Grüss
Matt

[Chefbastler]

Hab ebenfalls vor Jahren mal mit BASCOM in die Welt der Microcontroller eingestiegen.

Bischen C hatte hatte ich mit AVR-Studio 4(mit den höheren Versionen kam ich nicht zurecht) gemacht gehabt. Ging ganz gut ist aber mittlerweile auch nicht mehr Zukunftweisend.

Beruflich hab ich auch schon mit WinAVR zu tun gehabt, kommt mir mittlerweie auch Altmodisch und Unkonfortabel in der bedienung vor, ist aberauch brauchbar.

Heute bastel ich lieber mit STM32(Günstig und hatt schon Peripherie ohne Ende drin) und neheme Atollic Truestudio, da ist dann auch ein Debugger schon dabei. Giebt aber auch immerwieder mal noch Punkte wo ich noch nicht ganz durchblicke und mich ein/ducharbeiten muss.

[Bumbum]

Hallo,

wenn es erst mal AVR-Studio sein soll, kann ich nur die Version 4 empfehlen. Alles danach habe ich nie richtig zum laufen gebracht.

Die aktuellste Version wäre dann die V4.19. WinAVR ist nicht unbedingt notwendig. Man kann auch die AVR-eigene Toolchain herunterladen und nutzen. Damit habe ich in den letzten Jahren bessere Erfahrungen gemacht als mit WinAVR.

Das AVR-Studio 4 hat zumindest ein paar Vorteile im Vergleich zur Notepad++ Variante. (z.B. Fehlermeldungen, mit denen man zumindest die Ursache googlen kann, Simulation und die ISP Programmierung sollte mit jedem Programmer funktionieren)

Ich nutze diese IDE immer noch für die meissten meiner Atmel-Projekte, bin aber quasi damit "aufgewachsen" und weiß, wo die Nachteile sind. Die meissten wurde hier bereits genannt. Trotzdem bin ich bis jetzt immer ans Ziel gekommen.

Das ganze Arduino-Zeugs habe ich bisher immer geschafft zu überspringen. Ich habe mir meine Bibliotheken für diverse Hardware alle selbst geschrieben. Es ist bei mir ein Hobby und so lerne ich was dabei und weiß auch mit den Bibs umzugehen, falls was nicht funktioniert.

Viele Grüße
Andreas

[Hightech]

Ich habe Atmel Studio irgendwann gehasst.
Immer harkt und klemmt es. Besonders wenn man Libs und Projekte von anderen Leuten einbinden will.

C lernt man mit Studio nicht besser oder schlechter.

Aber ! man sollte sich mit Makefile beschäftigen, das ist wirklich sehr wichtig.
Man muss Makefile nicht verstehen, aber ein ganz einfaches Makefile sollte man je Projekt haben.

Das vorgehen bei mir ist z.B.

In einem Editor, welcher die C-Syntax versteht ein kleines C-Programm schreiben,

Dann wird mit Makefile das C-Programm compiliert und auf den Atmel gebrannt.
Das geht automatisch über Avrdude.

Im Makefile stehen dann die Optionen wie z.B. auch die Fuses drinne.
Wenn man in einem Programm alles schön zusammenklicken kann, lernt man das alles viel schwerer.

Ich komme von der IDE und bin jetzt auf der Konsole. Weil es so einfacher ist.

Als Profi kann man dann später die IDE benutzen, weil die Optionsfülle zu groß wird.
Aber anfangen sollte man mit einem Editor.

Das makefile ist ein Script, welches alles erledigt, bis zum brennen.

So sieht ein ganz einfaches makefile aus:

Code: Alles auswählen

PROJECT=hslave
SOURCES=$(PROJECT).c
MMCU=atmega88
F_CPU = 8000000UL

CFLAGS=-mmcu=$(MMCU) -Wall -g2 -Os -gstabs -fpack-struct -fshort-enums -ffunction-sections -fdata-sections -funsigned-char -funsigned-bitfields -fno-exceptions -std=c99 -DF_CPU=$(F_CPU)


$(PROJECT).hex: $(PROJECT).out
	avr-objcopy -O ihex $(PROJECT).out $(PROJECT).hex;\
	avr-size --mcu=$(MMCU) --format=avr $(PROJECT).out
	avrdude -p m88 -c avrispmkii -U flash:w:$(PROJECT).hex

$(PROJECT).out: $(SOURCES)
	avr-gcc $(CFLAGS) -I./ $(SOURCES) -o $(PROJECT).out

up:$(PROJECT).hex
	avrdude -p m88 -c avrispmkii -U flash:w:$(PROJECT).hex

Wenn mein Programm fertig ist scheibe ich einfach make und der rest geht von alleine.
Ich kann auch make up schreiben, dann brennt er einfach nur das hexFile auf den Atmel

[Weisskeinen]

Irgendwie bin ich da wohl anders gestrickt. Die Makefiles haben mich schon immer zum Kotzen gebracht (ich kann funktionsfähige erzeugen, ich will es aber nicht mehr) und Atmel-Studio läuft bei mir eigentlich sehr ordentlich, wenn es denn endlich mal mit Starten fertig ist. Auch die neueste Version.
Womit man anfängt, C zu programmieren ist letztlich egal. Ich würde aber ehrlich gesagt dafür nicht unbedingt mit der Mikrocontrollerprogrammierung anfangen, sondern auf dem PC bleiben. Und Kommandozeilenprogramme schreiben. Da muss man sich erst mal nicht um (beschränkte) Hardware kümmern und das Ausprobieren geht viel schneller. Man muss sich auch nicht um die verschiedenen Arten der Implementierung von Portzugriffen oder Interrupts kümmern, je nach dem, was für ein Kompiler zugrunde liegt. Auf jeden Fall weiß man, dass z.B. ein printf funktioniert und sucht nicht danach, ob das Display richtig angeschlossen ist, (noch) funktioniert, richtig initialisiert ist, eine Meldung so formatiert wird, dass das Display was damit anfangen kann, Zeilen umgebrochen oder hochgescrollt werden, etc. etc. etc..
Wenn man dann einige Sicherheit bei den Programmstrukturen hat, dann kann man sich m.E. an die Mikrocontroller wagen. Völlig egal, welche Entwicklungsumgebung man verwendet, in jede muss man sich einarbeiten. Da spielen viele persönliche Vorlieben eine Rolle, sieht man hier ja auch an den unterschiedlichen Empfehlungen.
Ich würde schon Atmel Studio empfehlen, als das raus kam, empfand ich das als großen Fortschritt gegenüber WinAVR. Die Version 6 hatte mich mal geärgert, aber das war mit der nächsten Unter-Unter-Version gegessen.
Die Microchip-IDE kenne ich noch nicht, vielleicht ist die auch gut... Editor, Makefiles, alles in der Shell aufrufen, finde ich mittlerweile total anachronistisch. Da hat man einen fetten Boliden mit beliebiger grafische Benutzeroberfläche auf oder unter'm Tisch stehen und benutzt die nur, um mehrere Shells nebeneinander darzustellen? Määäähhhh...

[Hightech]

Das liegt ja ein Problem, beim MC kann man nicht mal eben ein printf machen, dazu braucht man dann erstmal eine Schnittstelle (tty, Display etc.)
Ich debugge meistens mit einer LED an einem Port, so weiss ich dann, wo das Programm hängen bleibt.

Wenn z.B. die LED vor der LCD initialisierung blinkt aber danach nicht, ist es die LCD-init.
Blinkt die LED nicht im Sekundentakt, stimmt die Clock-Fuse nicht.

Meine Empfehlung bei C im zusammenhang mit MC ist so anzufangen:

Code: Alles auswählen

main.c

#include <avrzeugs >// Hier werden die Libs geladen
#include <avr/delay.h> //delay Lib laden

int main()   //Hauptprgramm

    while() //Hauptschleife
    DDRB|=(1<<PB0) //Port B0 als Ausgang schalten
    PORTB &=~(1<<PB0);// PortB Pin B0 anGND
    delay_ms(1000); // 1 Sekunde pause
    PORTB|=(1<<PB0);// PortB Pin B0 an VCC
   delay_ms(1000);// 1 Sekunde Pause

    ;//Ende Hauptschleife
;//Ende

Dafür braucht man keine IDE.
Der Compiler meckert dann schon wenn was nicht passt.
mit einem einfachen make ist das Programm dann auf dem MC und es blinkt vielleicht eine LED, wenn alles korrket ist.

Die IDE kommt viel später, wenn man den MC "drauf" hat.

Zum C lernen ist der MC auch nicht das richtige, denn dafür braucht man recht wenig vom C-Befehlssatz.
Außer man bastelt am TCP-Stack rum

[Fritzler]

Villeicht doch lieber mit ARM statt AVR anfangen?
Da kann man besser debuggen. Nämlich mit Debuggern über SWD/JTAG.
Um das beim AVR zu können muss man ordentlich Kohle fürn JTAG Debugger auf den Tisch legen.
Bei den STM32 Discovery Boards ist der bereits drauf und ein Jlink EDU kost auch grad mal 60 Schleifen.
(Jlink debuggt MERKLICH schneller als der ST onboard)

[TheOsram]

Vielen Dank für die zahlreichen Antworten.

Ich bin derzeit bei der Arduino IDE hängen geblieben. Display, Bluetooth und Ultraschall Sensor funktionieren.
Ich möchte mich aber nicht auf Arduino festlegen, da ich die Mega und Tinys auch separat schon verbaut habe.
Primär geht's um das Verständnis von C und die Anwendung dessen.

OSRAM

[Dr. Snuggles]

Hallo TheOsram,
ich nutze als Einsteiger mittlerweile nicht mehr die Arduino-IDE sondern Platform IO unter Atom.

Gruß
Doc

[Hightech]

Da stellt sich die Frage wofür willst du C verwenden, für MC Anwendungen oder für zB größere Programme?

C ist in Bezug auf die Datenverarbeitung nicht wirklich einfach. Wenn es dann los geht mit Pointern, Pointer auf Pointer auf Array. Das geht in Richtung Gehirnblutung.

[TheOsram]

Grundsätzlich als ein Modul fürs Studium, auch unter Einbindung von C++.
Dabei aber nur Grundlagen. Ich denke aber für mehr als die Programmierung von uC werde ich C wohl nicht benutzen wollen.
Und wie umfangreich dann die Programme werden, ergibt sich aus der 'Frickelei' die dann entsteht

PlatformIO sieht auf dem ersten Blick auch ziemlich spannend aus. ist da vom Editor bis zum Brennen des Chips alles möglich?

[xoexlepox]

Wenn es dann los geht mit Pointern, Pointer auf Pointer auf Array. Das geht in Richtung Gehirnblutung.

Vergiss nicht die Macros, Structures, Unions, und Pointer auf Funktionen In dem Bereich wird es dann richtig spassig! Wer sich mal solch "heftiges" C anschauen möchte, dem ist z.B. der Quellcode von Linux-Treibern zu empfehlen...

[Fritzler]

Funktionspointer returnender Funktionspointer:

Code: Alles auswählen

char (*process_user(char (*getfunktion)(struct ID3TAG_FIN*, unsigned *flags), struct ID3TAG_FIN* tagged, unsigned *flags))(struct ID3TAG_FIN*, unsigned *flags); 

Vllt doch lieber typedef.

[xoexlepox]

Funktionspointer returnender Funktionspointer

Herrlich! Wer da noch durchsteigt, der kann von sich behaupten, daß er "C kann". Aber das erfordert m.E. jahrelange Übung Es ist ein schönes Beispiel, wie flexibel und mächtig diese Sprache doch ist. Aber glücklicherweise kann man ja "klein anfangen"

[ch_ris]

Ich finde Jugendstil ja sehr Klasse.
Aber bei Code bin ich eher so der Bauhaus-Typ.
Man muss nicht alles machen nur weil's geht.

[Christian Knüll]

Bin da wohl ein bisschen Aussenseiter, denn ich mag das Atmel Studio für meine Zwecke sehr.
Bin allerdings mit Assembler anstatt C unterwegs - und dafür ist es eine schön kompakte Lösung mit vernünftigem Simulator.
Mit den heute üblichen, mehrere GB großen IDEs mit ihren zig Modulen und irrwitzig aufgeblasenen Libraries konnte ich mich dagegen nie anfreunden.

Wo ich allerdings definitiv übereinstimme: Atmel Studio 4 ist in mancherlei Hinsicht besser als neuere Versionen die dann auch zusehends den Weg der immer aufgeblaseneren IDEs eingeschlagen haben.

Mein Fazit: wer es kompakt mag und von der Art der Projekte her eher prozessornah / IO orientiert ist sollte sich das durchaus mal genauer ansehen.
Bei "high level" / userinterfacelastigen Aufgaben würde ich es allerdings auch nicht verwenden (und Richtung ARM tendieren).

Christian

[shaun]

Ich habe mir - weil Platine mit neuerem ATtiny war schon fertig - letztes Jahr notgedrungen das Studio 7 installiert und konnte damit bisher alle alten Projekte der letzten Jahre weiter be- und verarbeiten. Daher kann ich die Negativmeldunge nicht ganz bestätigen. Wenn es um das Lernen von C geht ist die Umgebung wirklich egal, mir wäre wichtig, dass sie zuverlässig funktioniert und ich bei der Fehlersuche nicht jedes Mal die Toolchain als Fehlerquelle mit einbeziehen muss. Das war bei mir beim Studio bisher der Fall.
Mit den STM32 bin ich noch gar nicht warm geworden, die Initialisierung und die Hardware-Abstraktion finde ich unhandlich und ein größeres Projekt, das angeblich auf dem Disovery 746 läuft lief bei mir so gar nicht, wohl, weil irgendein mitgeliefertes Treiberlein bei mir zu neu war und dann geht gleich gar nichts mehr? Wozu werden denn Schnittstellen definiert?! Und in ein paar tausend Zeilen Code im Neuland mal eben kurz die Ursache finden ist irgendwie uncool.

[Fritzler]

Die STM32 HAL ist auch einfach nur grottenschlecht und aufgeblasen -> nicht nutzen!
Dazu noch völlig verbuggt und mit Designentscheidungen wo man sich fragen muss ob die Entwickler geistig behindert sind.
Alles was man wissen muss steht im RefMan

Die Registerdefinitionen gibts ja genauso als Header wie bei AVR, nur ist diese Datei dann 1MB+ groß
Was man durchaus nutzen kann um etwas tipparbeit zu sparen ist de LowLevel API der STM32.
Das ist nicht weiter als der Registerzugriff per inlinefunktion etwas verpackt mit nem halbwegs sinnvollen Namen.