LED Leiste ansteuern

Ja, natürlich wenn der Ausgang auf 0 ist leuchtet die
jeweilige LED.

Hast Du die LED's richtig herum angeschlossen ?

Hallo,
sehr schön jetzt geht’s.
Abschließend hier der Quelltext.

1

#include <avr\io.h>

2

3

int main(void)

4

 {

5

   DDRA  = 0b11111111;

6

   PORTA = 0b00000000;

7

8

9

10

11

    while(1)

12

     {

13

14

        {

15

       DDRA = 1<<PA0; // Für Port A Pin 0

16

       DDRA = 1<<PA1; // Für Port A Pin 1

17

       DDRA = 1<<PA2; // Für Port A Pin 2

18

       DDRA = 1<<PA3; // Für Port A Pin 3

19

       DDRA = 1<<PA4; // Für Port A Pin 4

20

       DDRA = 1<<PA5; // Für Port A Pin 5

21

       DDRA = 1<<PA6; // Für Port A Pin 6

22

       DDRA = 1<<PA7; // Für Port A Pin 7       

23

        }

24

25

     }

26

 }

Danke!

PS.: Endlich habe ich den Login Button gefunden ; )

Wenn Du jetzt noch erklären kannst, was das in der while-Schleife 
bewirken soll.

Leuchten Dir die LEDs etwa zu hell?



Peter

Hi,
das hat eigentlich keinen Grund.

Ich habe das Programm erweitert so das alle Ports Auf ‚0‘ gesetzt werden 
jedoch leuchtet dann die LED an Port A7, B7, C7, D7 heller als alle 
anderen.

Ich habe einfach den Teil des Quelltexte der für das auf ‚0‘ setzen 
nötig ist kopiert und dann den Portbuchstaben ersetzt aber das 
funktioniert nicht richtig. Die letzte LED ist heller


Mit freundlichen Grüßen

Michael

Michael Justinger wrote:
> Hi,
> das hat eigentlich keinen Grund.

Warum hast Du es dann gemacht?

Programmzeilen sollten immer nen Grund haben, sonst schmeiß sie raus.


> Ich habe einfach den Teil des Quelltexte der für das auf ‚0‘ setzen
> nötig ist kopiert und dann den Portbuchstaben ersetzt aber das
> funktioniert nicht richtig. Die letzte LED ist heller

Ja, das muß so sein, weil Du Dir eben nichts dabei gedacht hast.

Du schaltest mit jeder Zeile die vorhergehende LED aus.


Peter

@ Peter Dannegger (peda)

>Du schaltest mit jeder Zeile die vorhergehende LED aus.

Für die Einen ist es ein Programmierfehler, für die Anderen das 
schnellste Lauflicht der Welt.

;-)
SCNR
Falk

Ich habe bis jetzt immer alles in einer while Schleife drinnen gehabt 
weil ich es so gelernt habe. Aber warum weis ich auch nicht. Der Lehrer 
meinte nur, dass es nötig sei damit das Programm läuft.

Soll ich etwa die Anweisung für einen kompletten Port in eine Zeile 
Schreiben und mit && verknüpfen?

Oder wie kann ich es erreichen, dass alle gleich hell sind und trotzdem 
alle Ports gesetzt werden.

Mit freundlichen Grüßen
Michel

Michael Justinger wrote:
> Ich habe bis jetzt immer alles in einer while Schleife drinnen gehabt
> weil ich es so gelernt habe. Aber warum weis ich auch nicht. Der Lehrer
> meinte nur, dass es nötig sei damit das Programm läuft.

Dann ist entweder dein Lehrer scheisse oder du hast nicht aufgepasst.

Eine While-Schleife wird immer dann gebraucht, wenn bestimmte Codezeilen 
zyklisch abgearbeitet werden sollen. Würdest du sie nicht setzen, würde 
der Kontroller deine Codezeilen einmalig abarbeiten und die Ausführung 
dann beenden und so lange nichts mehr tun, bis du ihn entweder Resetest 
oder über die Spannungsversorgnung neu startest.

> Soll ich etwa die Anweisung für einen kompletten Port in eine Zeile
> Schreiben und mit && verknüpfen?

Nein, so wie du diese Aufgabe geschildert hast, reicht es, wenn der 
Controller die Ausgänge auf '0' setzt uns sich dann beendet. Eine 
While-Schleife ist unnötig.

> Oder wie kann ich es erreichen, dass alle gleich hell sind und trotzdem
> alle Ports gesetzt werden.

Wenn dein Kontroller einmalig "PORTA=0;" ausführt, reicht daß, um ALLE 
Ausgänge dauerhaft auf '0' zu setzen. Eine einzelne Adressierungen 
einzelner Portleitungen ist nicht nötig, genausowenig wie irgendeine 
Whileschleife.

Die AVRLibC sorgt schon dafür, das dein Kontroller nicht übers Ziel 
hinausschiesst.

Hi,
ich habe immer kleine Programme geschrieben die Prüfen ob ein Pin ‚1‘ 
hat, das Programm sollte immer weiterlaufen weil an den Ports Sensoren 
waren die Abgefragt werden sollten.  Jetzt ist mir auch klar, dass eine 
while- Schleife hier unsinnig ist. Am Lehrer liegt es nicht, der ist 
gut.

Ich werde es mit "PORTA=0;" usw. ausprobieren und mich morgen wieder 
melden.

Danke für eure SCHNELLE Hilfe.



Mit freundlichen Grüßen


Michael

Michael Justinger wrote:

> Am Lehrer liegt es nicht, der ist gut.

LOL ;) Ein Schüler, der seinen Lehrer lobt. Das hat Seltenheitswert :)

> Ich werde es mit "PORTA=0;" usw. ausprobieren und mich morgen wieder
> melden.

DDRA=255; nicht vergessen ;)

Hi,
hab es heute Morgen ausprobiert und es funktioniert, erstaunlich wie 
hell die LED´s leuchten können.

Allerdings liegt an den Pins 24 – 27 keine Spannung an.
Das wäre
PC2 (TCK)
PC3 (TMS)
PC4 (TDO)
PC5 (TDI)

Warum ist das so?



Mit freundlichen Grüßen

Michael

Niels Hüsken wrote:

> genausowenig wie irgendeine
> Whileschleife.

Eine While-Schleife ist immer nötig!

Das Main darf nie verlassen werden!
Es gibt kein Betriebssystem, wohin die Ausführung zurückkehern kann.

Wenn aber nur einmalige und keine periodischen Aktionen auszuführen 
sind, dann ist die While-Schleife eben leer.


Peter

@ Peter Dannegger (peda)

>Eine While-Schleife ist immer nötig!

JAIN.

>Das Main darf nie verlassen werden!

JAIN.

>Es gibt kein Betriebssystem, wohin die Ausführung zurückkehern kann.

Sicher. Aber der WINAVR läuft danach in eine Endlosschleife, viele 
andere Compiler auch. JA, einige springen isn Nirvana, das ist dann 
schlecht.

MFG
Falk

Ich habe mal in dem Datenblatt nachgeschaut und folgendes gefunden:

• TDI – Port C, Bit 5
TDI, JTAG Test Data In: Serial input data to be shifted in to the 
Instruction Register or Data Register (scan chains). When the JTAG 
interface is enabled, this pin can not be used as an I/O pin.

• TDO – Port C, Bit 4
TDO, JTAG Test Data Out: Serial output data from Instruction Register or 
Data Register. When the JTAG interface is enabled, this pin can not be 
used as an I/O pin. The TD0 pin is tri-stated unless TAP states that 
shifts out data are entered.

• TMS – Port C, Bit 3
TMS, JTAG Test Mode Select: This pin is used for navigating through the 
TAP-controller state machine. When the JTAG interface is enabled, this 
pin can not be used as an I/O pin.

• TCK – Port C, Bit 2
TCK, JTAG Test Clock: JTAG operation is synchronous to TCK. When the 
JTAG interface is enabled, this pin can not be used as an I/O pin.

Ich konnte aber nicht finden welche Fuse-Bits ich setzen muss damit ich 
auch diese vier Ausgänge auf 0 setzen kann.

Datenblatt:
http://www.alldatasheet.com/view.jsp?Searchword=ATMEGA32

@ Michael Justinger (juston)

>Ich konnte aber nicht finden welche Fuse-Bits ich setzen muss damit ich
>auch diese vier Ausgänge auf 0 setzen kann.

???
Wie wäre es mit JTAGEN im Fuse High Byte?

MFG
Falk

aber achtung!!!
wie willst du ihn danach noch programmieren, wenn du jtag deaktiviert 
hast? ;-)

Ich glaube ich lass die  Konfiguration so wie sie ist. Mein Lehrer 
meinte wir sollten nicht mit den Fuse-Bit „experimentieren“. Ich 
verwende ja auch immer noch den internen Oszillator weil ich nicht weis 
welche Bits ich benötige für den externen Quarzoszillator zu verwenden.

Eigentlich sollte ich ja auch nur den Port A verwenden um die LED´s 
einzuschalten wenn der Pin eine ‚0‘ hat. Die Aufgabe ist ja erfüllt.

Als nächstes werde ich versuchen ein Lauflicht zu programmieren. (Aber 
diesmal nicht das schnellste der Welt.... LOL ).


Michael

Fuse ändern ist nicht nötig.

Man kann das JTAG auch per Software abschalten:

1

MCUCSR = 1<<JTD;

2

MCUCSR = 1<<JTD;

Peter

Hi,
habe eben mal das Programm für das Lauflicht fertig gestellt. Schaut es 
euch bitte mal an, es gibt sicher noch was zu verbessern.

Kompletter Programmordner
http://www.michaeljuston.de/lauflicht_test.zip


Mit freundlichen Grüßen

Michael

Code ist zwar kompletter unsinn, aber eines Interessiert mich dennoch. 
Welcher wirre Gedanke steckt hinter

1

   while (TCNT1 != 0) 

2

3

   {

4

5

       PINA = 0b11111111;     

6

7

   }

Das soll dafür sorgen das immer alle Ausgänge von Port A eine ‚1‘ haben 
und somit keine LED an ist. Natürlich nur solange bis der Zahler den 
Maximalwert erreicht hat und wieder bei 0 anfängt.

Komisch, das Programm läuft aber.
Wie hättet ihr denn das Programm geschrieben. Ich bin eigentlich kein 
Programmier.

Falk Brunner wrote:

> Sicher. Aber der WINAVR läuft danach in eine Endlosschleife, viele
> andere Compiler auch.

Nö, der macht RET, also Stackunderflow.

Dürfte 0x0000 oder 0xFFFF als Sprungziel ergeben, also nochmal von vorne 
über den Resetvektor.


> JA, einige springen isn Nirvana, das ist dann
> schlecht.

Ja, sieht man im Listing ganz deutlich:

1

int main( void )

2

{

3

  4c:   81 e0           ldi     r24, 0x01       ; 1

4

  4e:   88 bb           out     0x18, r24       ; 24

5

  PORTB = 1;

6

  return 0;

7

}

8

  50:   80 e0           ldi     r24, 0x00       ; 0

9

  52:   90 e0           ldi     r25, 0x00       ; 0

10

  54:   08 95           ret

Andere Compiler mögen eine Endlosschleife hinzufügen, der WINAVR aber 
nicht!

Man sollte aber trotzdem auch bei den anderen Compilern die Sachen extra 
hinschreiben, die nicht durch den C-Standard abgedeckt sind.


Peter

@Peda:

zumindest der neueste WINAVR knallt ne Endlosschleife rein:

1

00000382 <_exit>:

2

 382:  ff cf         rjmp  .-2        ; 0x382 <_exit>

(Auszug aus einem anderem Programm)

lg, Frank

Die LibC des AVR-GCC sorgt dafür das der Kontroller nach dem return aus 
der Main in einer Endlosschleife endet! Da bin ich mir 100% sicher.

Das kann Jörg Wunsch bestimmt bestätigen. Der sollte das wissen.

Evtl. Arbeitet Peda mit einer älteren Version der libc, in der das noch 
nicht drin war.
 Frank

Frank B_. wrote:
> zumindest der neueste WINAVR knallt ne Endlosschleife rein:

Stimmt (habs eben installiert), der WINAVR ist immer mal für ne 
Überraschung gut.

Aber dann spart die Loop immerhin 4 Bytes Code (oder man ignoriert die 
Warnung wegen dem fehlenden Return-Wert).

Wenns also spart, ein Grund mehr, C-konform zu sein.

Man sollte auch nicht absichtlich versionsabhängigen Code schreiben.


Peter

P.S.:
Ist auch nicht so der Brüller mit dem neuen Compiler beim ATtiny13 von 
den 64 Bytes SRAM nur 62 effektiv zu haben wegen der Main-Returnadresse.

Peter Dannegger wrote:

> Ist auch nicht so der Brüller mit dem neuen Compiler beim ATtiny13 von
> den 64 Bytes SRAM nur 62 effektiv zu haben wegen der Main-Returnadresse.

Wer auf die zwei Byte angewiesen ist, wäre ohnehin mit Assembler besser 
beraten. Mal abgesehen davon, daß man die Speicherzellen auch 
überschreiben kann, wenn man sie nicht braucht... Meine Meinung....