Atmega8 Einstiegsprobleme

@  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

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

@  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

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 ;)

So jetzt muss ich nochmal Nerven.

1

.include "m8def.inc"

2

3

         ldi r16, 0xFF

4

         out DDRC, r16

5

6

         ldi r16, 0xFF

7

         out PORTC, r16

8

9

ende:    rjmp ende

beim build kommt der Fehler:

1

 ***\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...?

Also mit dem AVR Assembler 1 gehts jetzt... komisch

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?

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...

1

#define  __AVR_ATmega8__  1

2

3

#include "avr/io.h"

4

5

void Initialize(void)

6

{

7

  PORTB = 0x0;

8

  PORTC = 1<<5;  /* turn the LED off */

9

  PORTD = 0x0;

10

11

  DDRB = 0x0;

12

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

13

  DDRD = 0x0;

14

15

}

16

17

/*  state = 0 -> Led Off

18

 *  state = 1 -> Led On

19

 *  state !=[0,1] -> Led Toggle 

20

 */

21

void LedSet(unsigned char state)

22

{

23

  switch (state)

24

  {

25

    case 0:

26

      PORTC &= ~(1<<5);

27

      break;

28

    case 1:

29

      PORTC |= 1<<5;

30

      break;

31

    default:

32

      if (PORTC & 1<<5) 

33

        PORTC &= ~(1<<5);

34

      else

35

        PORTC |= 1<<5;

36

  }

37

38

}

39

40

41

int main(void)

42

{

43

  int i;

44

45

  Initialize();

46

47

  while (1)

48

  {

49

    LedSet(0);

50

    for (i=60000;i;i--);

51

    LedSet(1);

52

    for (i=60000;i;i--);

53

  }

54

  return 0;

55

}

Also das wär jetzt der Blink LED Code.

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

Ich probier einfach mal beides aus und entscheid mich dann...

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

@  Иван 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?

spess53 schrieb:
> Was funktioniert nicht?

1

.include "m8def.inc"

2

3

         ldi r16, 0xF

4

         out DDRC, r16  ;PortC als Ausgang definieren

5

6

         ldi r16, 0xF

7

         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?

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:

1

.include "m8def.inc"

2

3

         ldi r16, 0xFF

4

         out DDRC, r16

5

6

         ldi r16, 0x00

7

         out PORTC, r16

8

9

ende:    rjmp ende

Gruß
Lasse

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

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

void MAIN(*irgendwas)

6

7

int  set_my_port_c_to_function(#alternative);

8

void all_my_pins_are_leddriver(*port_C);

9

int  set_drive_mA(*portC,#CURRENT_OPTION_HI);

10

void light(*portC)

11

12

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

@  Иван 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

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

Intoleranter Zeitgenosse!

Иван

@  Иван 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

void main()

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?

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.