mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Atmega8 Einstiegsprobleme


Autor: Sebastian E. (musarati)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: swen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: swen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
....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

Autor: swen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sebastian E. (musarati)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: swen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: swen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
achja...vergiss nich WINAVR für C zu installieren, wenns den C sein soll

http://sourceforge.net/projects/winavr/files/

swen

Autor: Sebastian E. (musarati)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Sebastian E. (musarati)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: Sebastian E. (musarati)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So jetzt muss ich nochmal Nerven.
.include "m8def.inc"
 
         ldi r16, 0xFF
         out DDRC, r16
 
         ldi r16, 0xFF
         out PORTC, r16
 
ende:    rjmp ende

beim build kommt der Fehler:
 ***\m8def.inc(321): error: Attempt to redefine keyword 'or'

Wenn ich das richtig interpretiere findet er einen Fehler in der 
m8def.inc, an der ich aber nicht gemacht hab...?

Autor: Sebastian E. (musarati)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also mit dem AVR Assembler 1 gehts jetzt... komisch

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sebastian E. (musarati)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>hatte die include datei ins verzeichniss kopiert... das war anscheinend
>der Fehler

Ja. Lass sie dort wo sind.

MfG Spess

Autor: Sebastian E. (musarati)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
ldi r16, 0xFF
out DDRC, r16
definiert alle PCX als ausgänge

und
ldi r16, 0xFF
out PORTC, r16

aktiviert alle diese Ausgänge?

Oder liege ich da falsch?

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sebastian E. (musarati)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...
#define  __AVR_ATmega8__  1

#include "avr/io.h"

void Initialize(void)
{
  PORTB = 0x0;
  PORTC = 1<<5;  /* turn the LED off */
  PORTD = 0x0;

  DDRB = 0x0;
  DDRC = 1<<5;  /* PC5 as output - the LED is there */
  DDRD = 0x0;

}

/*  state = 0 -> Led Off
 *  state = 1 -> Led On
 *  state !=[0,1] -> Led Toggle 
 */
void LedSet(unsigned char state)
{
  switch (state)
  {
    case 0:
      PORTC &= ~(1<<5);
      break;
    case 1:
      PORTC |= 1<<5;
      break;
    default:
      if (PORTC & 1<<5) 
        PORTC &= ~(1<<5);
      else
        PORTC |= 1<<5;
  }
  
}


int main(void)
{
  int i;

  Initialize();

  while (1)
  {
    LedSet(0);
    for (i=60000;i;i--);
    LedSet(1);
    for (i=60000;i;i--);
  }
  return 0;
}

Also das wär jetzt der Blink LED Code.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Иван S. (ivan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sebastian E. (musarati)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich probier einfach mal beides aus und entscheid mich dann...

aber im Moment zwickts irgendwo.. ich weiß nur noch nicht wo -,-

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Иван 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

Autor: Hc Zimmerer (mizch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sebastian E. (musarati)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sebastian E. (musarati)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:
> Was funktioniert nicht?
.include "m8def.inc"

         ldi r16, 0xF
         out DDRC, r16  ;PortC als Ausgang definieren

         ldi r16, 0xF
         out PORTC, r16  ;PortC Ausgänge aktivieren

an dem Ausgang PC5 hängt eine LED dran, die im Beispielprojekt auch 
leuchtet...
Bei meinem selbstgeschriebenen Code nicht...

Irgendeine Idee?

Autor: Lasse S. (cowz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
.include "m8def.inc"
 
         ldi r16, 0xFF
         out DDRC, r16
 
         ldi r16, 0x00
         out PORTC, r16
 
ende:    rjmp ende

Gruß
Lasse

Autor: Sebastian E. (musarati)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
ende:    rjmp ende

drunter?

Das ganze macht doch nur sinn wenn man auch was in der Schleife hat, 
oder?

Autor: Lasse S. (cowz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: AchtVolt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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^^

Autor: Иван S. (ivan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
INCLUDE "ez8.inc"                       ; Definitionsdatei für eZ8 inkludieren

VECTOR RESET = startme                  ; Den Resetvektor nennen wir "startme"

startme:
  LDX PCADDR,#%07      ; Adressregister Port C für alternative Portfunktion beladen
  LDX PCCTL, #%FF      ; Alle Pins auf alternative Funktion (Led-Treiber)
  LDX LEDEN, #%FF      ; LED-Treiber für alle Pins von Port C konfigurieren
  LDX LEDLVLH,#%FF    ; LED-Treiber auf 13mA einstellen (LED leuchtet)
  JP startme

vs.

#include <iks.h>
#include <uepsilon.h>
#include <zett.h>

void MAIN(*irgendwas)

int  set_my_port_c_to_function(#alternative);
void all_my_pins_are_leddriver(*port_C);
int  set_drive_mA(*portC,#CURRENT_OPTION_HI);
void light(*portC)

goto main();


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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Иван 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

Autor: Иван S. (ivan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
> @  Иван S. (ivan)
> Womit ich wieder bei meiner alten Aussage wäre. Elektronikautismus.

Intoleranter Zeitgenosse!

Иван

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Könnt ihr nicht woanders spielen gehen?

MfG Spess

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Иван 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

Autor: Иван S. (ivan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Иван 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.

Autor: Michael G. (let)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
#include <ez8.h>

void main()
{
   for (;;) {
      PCADDR  = 0x07;  // Adressregister Port C für alternative Portfunktion beladen
      PCCTL   = 0xff;  // Alle Pins auf alternative Funktion (Led-Treiber)
      LEDEN   = 0xff;  // LED-Treiber für alle Pins von Port C konfigurieren
      LEDLVLH = 0xff;  // LED-Treiber auf 13mA einstellen (LED leuchtet)
   }
}
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?

Autor: swen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: ein Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: ein Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael G. (let)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.