Hallo,
ich habe seit kurzem das "AVR Starterkit" aus dem Shop.
Das Draufstecken, den USBprog zusammenlöten, auch die Beisppielprojekte
draufspielen ging alles ganz einfach.
Ich mus zwar sagen das alles schlecht dokumentiert ist, und das man
erstmal drauf kommen muss was ich jetzt wofür brauche (nicht gerade
Einsteigerfreundlich das ganze...) aber es hat einigermaßen geklappt.
Jetzt aber mal zu meiner eigentlichen Frage:
Ich lese grad das AVR-Tutorial: IO-Grundlagen durch, und hab das
ganze mal mit dem Source von den Beispielen verglichen und kann da
einfach keinen Zusammenhang finden.
Da wird auch (ich vermute mal das ist C oder so) irgendwie mit
Funktionen gearbeitet...
Ich hab kaum Ahnung von höheren Sprachen wie C, und bin totaler Neuling
auf dem Gebiet...
also:
- Ist das Tut das richtige für mich?
if $answer1 = "True"
;) Soll ich einfach mal den ganzen Kram aus dem Beispiel rausschmeißen
und nach dem Tut arbeiten
- Gibts irgendwelche Tuts die genau auf dem Board aufbauen?
- Gibts ne ausführliche Erklärung von dem Source der Beispiele?
Vielen Dank für eure Hilfe
Sebastian
Sebastian B. schrieb:
> Da wird auch (ich vermute mal das ist C oder so) irgendwie mit> Funktionen gearbeitet...
nee das tutorial ist für assemblerprogrammierung.
für c gibts: http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial.
einfahc mal durcharbeiten, dann klappts auch mit dem nachbarn äh
controller
mfg swen
@ Sebastian B. (musarati)
>Ich lese grad das AVR-Tutorial: IO-Grundlagen durch, und hab das>ganze mal mit dem Source von den Beispielen verglichen und kann da>einfach keinen Zusammenhang finden.>Da wird auch (ich vermute mal das ist C oder so) irgendwie mit>Funktionen gearbeitet...
Kann sein.
>- Ist das Tut das richtige für mich?
Ja.
>;) Soll ich einfach mal den ganzen Kram aus dem Beispiel rausschmeißen>und nach dem Tut arbeiten
Ja.
>- Gibts irgendwelche Tuts die genau auf dem Board aufbauen?
AFAIK nein.
>- Gibts ne ausführliche Erklärung von dem Source der Beispiele?
Keine Ahnung.
Arbeite das Tutorial Schritt für Schritt durch, dann lernst du sehr
viel.
Mfg
Falk
....was aber jetzt nicht heissen soll nimm C. wenn du eh neu anfängst
kannst du dich auch an assembler versuchen, ist wahrscheinlich sogar für
den µC besser, weil wers damit draufhat, bekommt sehr schnellen code.
das problem ist aber das du dich extrem auf die spezielle hardware
"einschiesst" also net mal schnell die plattform/typ wechseln kannst...
ich bin leider ;-) c-vorbelastet von daher keine lust auf assembler.
mfg swen
Falk Brunner schrieb:
>>Ich lese grad das AVR-Tutorial: IO-Grundlagen durch, und hab das>>ganze mal mit dem Source von den Beispielen verglichen und kann da>>einfach keinen Zusammenhang finden.>>>Da wird auch (ich vermute mal das ist C oder so) irgendwie mit>>Funktionen gearbeitet...>> Kann sein.>>>- Ist das Tut das richtige für mich?>> Ja.
@ Falk Brunner
wasn das für ne hilfe??
> Kann sein.>>>- Ist das Tut das richtige für mich?>> Ja.
entweder du weisst was in den tut steht um eine empfehlung abzugehen
oder du solltest es besser lassen.
OK also mal zusammengefasst:
entweder ich Programmier den Atmega in C oder in Assembler.
IMHO: C wird ja vom Studio in Assembler übersetzt, da das ganze aber
maschinell verarbeitet wird ists nicht so schnell - richtig?
Assembler: schnelle, kompliziertere aber auch Controllergebundene
Sprache
C: universelle, relativ einfache Sprache, überall einsetzbar
Soviel ich weiß ist aber Assembler bei allen Atmegas relativ gleich
oder?
leicht OT:
Wenn ich in AVR Studio ein neues Projekt erstelle fragt er mich nach
einem Projekt Typ - GCC oder Assembler (wähle ich jetzt dann die Sprache
oder?) und wenn ich dann Assembler nehme, will er eine "Debug Plattform"
haben.
Was ist das? Ist das der USBProg? Das Device ist ja dann der Atmega 8
aber woher weiß ich welcher genau?
Grüße & Danke für eure Hilfe
Sebastian
Hi
>und wenn ich dann Assembler nehme, will er eine "Debug Plattform">haben. Was ist das? Ist das der USBProg?
Nur wenn den USBProg JTAG oder Debugwire unterstützt. Im einfachsten
Fall stelle AVR Simulator oder AVR Simulator2 (je nach Controller) ein.
MfG Spess
@ Sebastian E. (musarati)
>IMHO: C wird ja vom Studio in Assembler übersetzt, da das ganze aber>maschinell verarbeitet wird ists nicht so schnell - richtig?
Falsch. Nur ein Assemblerprofi generiert besseren (schnelleren)
Assemblercode als ein Compiler. Für den "Normalprogrammierer" ist es
kein nennenswerter Unterschied.
>Assembler: schnelle, kompliziertere aber auch Controllergebundene>Sprache
ja.
>C: universelle, relativ einfache Sprache, überall einsetzbar
Ja.
>Soviel ich weiß ist aber Assembler bei allen Atmegas relativ gleich>oder?
Ja.
>einem Projekt Typ - GCC oder Assembler (wähle ich jetzt dann die Sprache>oder?)
ja.
> und wenn ich dann Assembler nehme, will er eine "Debug Plattform">haben.>Was ist das?
Na deine Methode zum Debuggen/Fehler suchen. Meist nimmt man einfach den
Simulator.
> Ist das der USBProg?
Nein, das ist ein einfacher Programmieradapter, mit dem kann man nicht
debuggen.
MfG
Falk
naja, soweit ich das von einem assembler "profi" gehört habe ist
assembler eigentlich gar nicht schwer. es wäre wie mit der entscheidung
snowboard / ski. wenn man nichts von beiden kennt ist das eine nicht
schwerer als das andere. wenn man aber z.b. lange zeit ski fährt, dann
fällt ein der versuch mit snowboard zu fahren unheimlich schwer, weil
man halt seine ollen "synapsen" :) auf ski geprägt hat. (so gehts mir
mit ski.
ich würd gerne was in assembler machen, schon alleine wegen der
direktheit, der totalen kontrolle über jeden zustand und der
geschwindikteit/speicherplatzverbrauch. kommt aber erst nächstes jahr
wenn ich "muss" :) (mache gerade nen e-techniker datenverarbeitung)
also schupper in beides rein und entscheide dich.
Sebastian E. schrieb:
> leicht OT:> Wenn ich in AVR Studio ein neues Projekt erstelle fragt er mich nach> einem Projekt Typ - GCC oder Assembler (wähle ich jetzt dann die Sprache> oder?)
jo
und wenn ich dann Assembler nehme, will er eine "Debug Plattform"
> haben.> Was ist das? Ist das der USBProg? Das Device ist ja dann der Atmega 8> aber woher weiß ich welcher genau?
dann kommt ne auswahl mit was du den proggen willst
atmega 8 gibst nur in normal und (L) oder?
mfg swen
Falk Brunner schrieb:
>> und wenn ich dann Assembler nehme, will er eine "Debug Plattform">>haben.>>Was ist das?>> Na deine Methode zum Debuggen/Fehler suchen. Meist nimmt man einfach den> Simulator.
Ah Ok verstanden, Danke dir!
swen schrieb:
> wenn ich "muss" :) (mache gerade nen e-techniker datenverarbeitung)>> also schupper in beides rein und entscheide dich.
xD cool ich will mich gerade mit sowas drauf vorbereiten ;)
Hi
>Also mit dem AVR Assembler 1 gehts jetzt... komisch
Nein nicht komisch. Du hast die falsche Include-Datei. Der
AVR-Assembler2 sucht die Datei automatisch. Du hast mit dem Eintrag in
'Assembler Options->Additional Include Path' diese Sucherei auf die
falsche Datei gelenkt. Lass mal den Eintrag leer und assembliere noch
mal mit Assembler2.
MfG Spess
hatte die include datei ins verzeichniss kopiert... das war anscheinend
der Fehler
[code]
.include "m8def.inc"
ldi r16, 0xFF
out DDRC, r16 ;PortC als Ausgang
ldi r16, 0xFF
out PORTC, r16 ;PortC Ausgänge aktivieren
[code]
theoretisch müsste jetzt jede LED leuchten, die an dem Port C Bereich
hängt - oder?
Stand so im Tut drin...
> Wichtig ist, dass sich die Datei "m8def.inc" (wird beim Atmel-Assembler >
mitgeliefert) im gleichen Verzeichnis wie die Assembler-Datei befindet
Kann mir jemand sagen wie das mit den Ausgängen?
Also ich weiß mittlerweile das meine LED irgendwo im PortC Bereich
liegt.
Allerdings muss ich noch n Fehler drin haben, da die LED nicht
leuchtet...
Was für mich interessant wäre:
Wenn ich eine LED an einem PIN habe, kann ich ja über die Doku
herrausfinden welcher "Bereich" das ist... also bei mir Pin 28, also
PC5.
das heißt
1
ldi r16, 0xFF
2
out DDRC, r16
definiert alle PCX als ausgänge
und
1
ldi r16, 0xFF
2
out PORTC, r16
aktiviert alle diese Ausgänge?
Oder liege ich da falsch?
Hi
>kann ich ja über die Doku herrausfinden welcher "Bereich" das ist..
Nenne es einfach Port.
>...aktiviert alle diese Ausgänge?>Oder liege ich da falsch?
Nein. Aber ob deine Led dann leuchtet, hängt davon ab, wie sie
angeschlossen ist.
MfG Spess
spess53 schrieb:
> Nein. Aber ob deine Led dann leuchtet, hängt davon ab, wie sie> angeschlossen ist.
Naja per Vorwiderstand...
Mit der Beispielanwendung funktionierts ja... Die ist aber in C
geschrieben...
Hi
>Naja per Vorwiderstand... Mit der Beispielanwendung funktionierts ja... Die >ist
aber in C
Aber es gibt 2 Möglichkeiten die LED anzuschliessen:
VCC-Vorwiderstand-LED-PIN ->Leuchtet wenn Pin=L
PIN-Vorwiderstand-LED-GND ->Leuchtet wenn Pin=H
MfG Spess
Falk Brunner schrieb:
>>Assembler: schnelle, kompliziertere aber auch Controllergebundene>>Sprache>> ja.>>>C: universelle, relativ einfache Sprache, überall einsetzbar>> Ja.
Ich will weder den Thread von Sebastian E. versauen, noch einen Flamewar
"Assembler vs. C" anzetteln. Aber du provozierst ja förmlich einen
Kommentar!
Die Auffassung, Assembler sei "kompliziert" und C sei "einfach" ist rein
subjektiv. Im übrigen ist meiner Meinung nach auch Assembler "überall
einsetzbar".
Iwan
@ Иван S. (ivan)
>Die Auffassung, Assembler sei "kompliziert" und C sei "einfach" ist rein>subjektiv. Im übrigen ist meiner Meinung nach auch Assembler "überall>einsetzbar".
Das ist deine Meinung. Beschränkt auf den Basteleinsatz. Warum wohl
programmiert heute kaum noch einer in Assembler im professionellen
Bereich? Könnte das was mit der deutlich größeren Komplexität der
Software zu tun haben, welche mit C deutlich besser zu handhaben ist?
MFG
Falk
Ich habe keine Ahnung, wovon ihr redet. Seit ich im Beruf bin (und das
sind jetzt ca. 30 Jahre) programmiere ich nicht entweder in Assembler
oder Hochsprache, sondern fast immer in beidem fürs gleiche Projekt.
Die Kombination macht's: man nimmt einfach die Sprache, die einem für
diesen Teil der Aufgabe am besten geeignet erscheint.
ASM/C entweder/oder ist Einsteigerperspektive (aus meiner Sicht). The
right tool for the right Job.
Ich dachte das sollte keine Grundsatzdiskussion werden?!?
BtT:
Es funktioniert immernoch nicht...
Im C geschriebenen Projekt wird noch ein I/O Modul eingebunden.
brauch ich sowas auch? Ich denke doch nicht oder?
Hi
>Es funktioniert immernoch nicht...
Was funktioniert nicht?
>Im C geschriebenen Projekt wird noch ein I/O Modul eingebunden.>brauch ich sowas auch? Ich denke doch nicht oder?
Brauchst du nicht.
MfG Spess
Hi,
spess53 schrieb:
> Aber es gibt 2 Möglichkeiten die LED anzuschliessen:>> VCC-Vorwiderstand-LED-PIN ->Leuchtet wenn Pin=L> PIN-Vorwiderstand-LED-GND ->Leuchtet wenn Pin=H
Hast du das gelesen?
Versuch mal folgenden Code:
hmm jetzt gehts...
ich muss ihn also auf 0 setzen - d.H. die Led ist anscheinend auf VCC
gelegt...
Da muss man mal drauf kommen -,-
Vielen Dank!!!
Warum schreibt man eig.
1
ende: rjmp ende
drunter?
Das ganze macht doch nur sinn wenn man auch was in der Schleife hat,
oder?
Glückwunsch zur leuchtenden LED! :)
Die Endlosschleife am Ende ist dafür da, damit der Code irgendwann
aufhört. Ansonsten läuft der einfach über den ganzen Speicher und ist
irgendwann am Ende (und fängt dann wieder am Anfang an). Da man das
nicht will, pflanzt man an's Ende ne Endlosschleife.
Später, bei komplexeren Programmen wird die dann auch mit was gefüllt :)
Gruß
Lasse
Hi
>Warum schreibt man eig.>ende: rjmp ende
Das Programm bleibt an der Stelle stehen. Sonst wird der Controller das
was nach dem Programm im Speicher steht einfach als Befehle
interpretieren und unkontrolliert weitermachen.
>Das ganze macht doch nur sinn wenn man auch was in der Schleife hat,>oder?
Jain. Z.B. kann das Programm auf Interrupts warten. Allgemein gesehen
hast du Recht.
MfG Spess
Hoi,
der Programmcounter zählt immer hoch sobald der nächste Befehl ansteht.
Sollte er jetzt also bei "out PORTC, r16"sein, findet er als nächstes
ein leeres Byte(da steht ja nix). Das interpretiert er als NOP und
erhöht den ProgrammCounter weiter. Jetzt ist wieder n leeres Byte da,
also das nächste NOP...usw und sofort. Irgendwann ist er am Ende vom
Programmspeicher angekommen(nach tausenden von NOPs).
Jetzt fängt er von vorne an.
Und würde dein Programm nochmal komplett neu ausführen.
Für dein einfaches Beispiel ist es egal, aber bei größeren Programmen
kommt es zu Problemen wenn er andauernd neu anfängt.
Deswegen die Endlosschleife.
//edit:
arg^, zu langsam^^
Falk Brunner schrieb:
> @ Иван S. (ivan)>>>Die Auffassung, Assembler sei "kompliziert" und C sei "einfach" ist rein>>subjektiv. Im übrigen ist meiner Meinung nach auch Assembler "überall>>einsetzbar".>> Das ist deine Meinung. Beschränkt auf den Basteleinsatz.
Das ist durchaus auch im industriellen Umfang relevant. In Pseudocode:
1
INCLUDE "ez8.inc" ; Definitionsdatei für eZ8 inkludieren
2
3
VECTOR RESET = startme ; Den Resetvektor nennen wir "startme"
4
5
startme:
6
LDX PCADDR,#%07 ; Adressregister Port C für alternative Portfunktion beladen
7
LDX PCCTL, #%FF ; Alle Pins auf alternative Funktion (Led-Treiber)
8
LDX LEDEN, #%FF ; LED-Treiber für alle Pins von Port C konfigurieren
9
LDX LEDLVLH,#%FF ; LED-Treiber auf 13mA einstellen (LED leuchtet)
10
JP startme
vs.
1
#include<iks.h>
2
#include<uepsilon.h>
3
#include<zett.h>
4
5
voidMAIN(*irgendwas)
6
7
intset_my_port_c_to_function(#alternative);
8
voidall_my_pins_are_leddriver(*port_C);
9
intset_drive_mA(*portC,#CURRENT_OPTION_HI);
10
voidlight(*portC)
11
12
gotomain();
Dazu dann noch die Compiler- und Linkeroptionen. Wer's braucht, bitte
sehr.
> Warum wohl programmiert heute kaum noch einer in Assembler im> professionellen Bereich?
Ach, tut man dies nicht? Das wäre mir neu.
> Könnte das was mit der deutlich größeren Komplexität der> Software zu tun haben, welche mit C deutlich besser zu handhaben ist?
Glaub' ich nicht.
> MFG> Falk
MFG
Iwan
@ Иван S. (ivan)
>> Warum wohl programmiert heute kaum noch einer in Assembler im>> professionellen Bereich?>Ach, tut man dies nicht? Das wäre mir neu.
Dir ist vieles neu, was für den Rest der Welt alt ist.
>> Könnte das was mit der deutlich größeren Komplexität der>> Software zu tun haben, welche mit C deutlich besser zu handhaben ist?>Glaub' ich nicht.
Musst du auch nicht. In deinem kleinen Bastelzimmer in den Bergen kannst
du dir die Welt mit allen Farben ausmalen, die du kennst. Womit ich
wieder bei meiner alten Aussage wäre. Elektronikautismus.
MFG
Falk
@ Иван S. (ivan)
>> Womit ich wieder bei meiner alten Aussage wäre. Elektronikautismus.>Intoleranter Zeitgenosse!
Du verwechselst Toleranz mit einstimminger Meinung. Ich toleriere deine
Meinung, wenn gleich ich sie nur im Hobbybereich akzeptiere. Aus
rationalen Gründen.
MFG
Falk
Falk Brunner schrieb:
>>> Womit ich wieder bei meiner alten Aussage wäre. Elektronikautismus.>>Intoleranter Zeitgenosse!> Du verwechselst Toleranz mit einstimminger Meinung.
Aha, deine persönliche, subjektive Ansicht ist also "einstimmige
Meinung".
> Ich toleriere deine Meinung, wenn gleich ich sie nur im Hobbybereich> akzeptiere. Aus rationalen Gründen.
Ich toleriere und akzeptiere Deine Meinung. Mögest Du doch glauben, was
Du willst. Ich postuliere die Relevanz von Assembler auch in der
Industrie.
Iwan
@Иван S. (ivan)
>Aha, deine persönliche, subjektive Ansicht ist also "einstimmige>Meinung".
Du verwechselst mal wieder einstimmig mit objektiv richtig.
Wenn du und ich einer Meinung wären, wäre das einstimmig.
Was objektiv richtig ist, weiß nur der liebe Gott.
>Ich toleriere und akzeptiere Deine Meinung. Mögest Du doch glauben, was>Du willst. Ich postuliere die Relevanz von Assembler auch in der>Industrie.
Das ist wohl wahr.
http://de.wikipedia.org/wiki/Postulat
MfG
Falk
P S Ich liebe Wikipedia.
Natürlich ist Assembler in der Industrie relevant. Die Frage
ist nur wo und warum wird es eingesetzt und in welchem Umfang?
In den meisten Fällen bietet Assembler einfach keinen nutzbaren
Vorteil. Man verschenkt aber Wiederverwendbarkeit (ich rede hier
nicht von Code-Snippets und Libraries) und Portabilität.
Nicht unterschätzen sollte man auch die Entwicklungszeiten.
Diese fallen nicht nur für Neuentwicklungen an, sondern auch
für Modifikationen - Monate später.
Es heißt ja immer 'Zeit ist Geld'. Im industriellen Bereich stimmt
das so nicht, denn dort ist Zeit oft wichtiger als Geld.
Dennoch ist es sicher kein Fehler als Anfänger mit Assembler
zu beginnen. Es hilft die Architektur zu verstehen und außerdem
gilt:
Hobby != Industrie
Das ist völlig wertfrei gemeint. Und um C kann man sich ja auch
später noch kümmern. Oder auch nicht. Jedem das seine - solange
es nur ein Hobby ist und auch bleiben soll.
PS: Das gezeigte Assemblerprogramm vernünftig in C:
1
#include<ez8.h>
2
3
voidmain()
4
{
5
for(;;){
6
PCADDR=0x07;// Adressregister Port C für alternative Portfunktion beladen
7
PCCTL=0xff;// Alle Pins auf alternative Funktion (Led-Treiber)
8
LEDEN=0xff;// LED-Treiber für alle Pins von Port C konfigurieren
9
LEDLVLH=0xff;// LED-Treiber auf 13mA einstellen (LED leuchtet)
10
}
11
}
Ein Makefile sollte man dafür aber schon schreiben bzw. ein vorhandenes
entsprechend anpassen - zumindest dann wenn man keine IDE verwendet.
Braucht man das für Assembler nicht?
aber eins kann man nicht abstreiten: nen µC ohne quellcodes kann man
deassemblieren (auslesen und den maschienecoe lesbar machen) - ohne
assemblerknowhow keine chance was zu verstehen. es gibt firmen die
suchen leute für sowas. (kenn ich jemanden). da muss es aber auch um was
essentielles gehen sonst macht sowas keiner. der verdient richtig gut.
der wird gehandelt wie vertvole aktien. (ich vermute mal da gehts wohl
um aufdecken von "geklauten" code in produkten anderer hersteller)
von daher kann es nicht schaden etwas davon zu verstehen. evtl kann man
damit sch ne stelle in der industrie sichern.
mfg swen
Hi
Sebastian möge mir verzeihen.
>Man verschenkt aber Wiederverwendbarkeit (ich rede hier> nicht von Code-Snippets und Libraries) und Portabilität.
Wovon dann?
Und wo ist dir portierbakeit von C-Programmen, in denen auf
controllerspezifische Register zugegriffen wird?
MfG Spess
Also ich bin auch noch Anfänger,
ich hab den GT-100 vom ELV nachprogrammiert
nur halt mit LCD und das war in Assembler
zum Schluss hab ich dann den Überblick verloren.
es war aber auch nicht sehr schön strukturiert.
C kenne ich nur vom Pc programmieren
da behält man wunderbar den Überblick
aber einfacher ist es auch nicht.
Meine PC-Programme in Assembler sind
um einiges kleiner als in C
Wies bei GCC für AVR aussieht weis ich leider nicht.
spess53 schrieb:
> Und wo ist dir portierbakeit von C-Programmen, in denen auf> controllerspezifische Register zugegriffen wird?
ich benutze nur Atmega8 aber da ist asebler auch nicht recht schwer
Hi
>ich benutze nur Atmega8 aber da ist asebler auch nicht recht schwer
Ist es auch auf anderen nicht. Und wenn du dich mal richtig mit
Assembler z.B. Preprocessor, Macros, Assembler directives etc.
beschäftigst, wirst du ungeahnte Möglichkeiten entdecken.
MfG Spess
spess53 schrieb:
> Wovon dann?
Von der eigentlichen Programmlogik.
> Und wo ist dir portierbakeit von C-Programmen, in denen auf> controllerspezifische Register zugegriffen wird?
Du meinst diese 200 Zeilen Code um spi_xx(), i2c_xx(), get_timer() etc.
abzubilden? Den Teil muß man für jede Architektur einmal neu
schreiben. Kann man auch in Assembler machen. Doch das Programm
selbst, sein TCP Stack, das LCD-Menü um den Klangsteller zu
parametrieren, das kann praktisch unverändert übernommen werden.
Portieren und Wiederverwenden von Code können Leuten machen die den
Originalcode nicht geschrieben haben und ihn kaum kennen. Sie
müssen ja nur den low-level Kram bereitstellen. Und wenn der Code
verstanden werden muß, dürfte das bei C einfacher sein.
Bei compilerspezifischen Dingen - beim CCS-C ist der 'int' z. B. 8Bit
groß und unsigned - muß der Code entsprechend überarbeitet werden.
Das kann aber mehr oder weniger mechanisch geschehen da unabhängig
von der Programmlogik.