atmega8535 - 6-aus-8-zähler Programmierung

Hi,

Und wir haben schon eine neue Aufgabe:
Wir sollen eine schleife Programmieren, die genau 1 Sekunde lang brauchen soll um bearbeitet zu werden. Leider nur mit den Befehlen die schon im ersten Post genannt wurden.
für ne neue Aufgabe wär glaube ich nen neuer Thread ganz vernünftig. Dann sieht man anhand des Titels um was es sich handelt.

Normalerweise macht man solche Zeitaufgaben über einen Timer um noch Rechenzeit für das "normale" Programm übrig zu haben. Wenn man einfach in einer Schleife wartet bis die Zeit um ist, dann mancht der Prozessor in der Zeit ja nix anderes. Das wäre totale Resourcenverschwendung.

Ich tippe mal ihr sollt anhand der Aufgabe die Zeitplanung lernen. Also zB wieviel Zeit er für einen Befehl benötigt und wie man Ablaufzeiten von Programmteilen berechnen kann.

Ist eigentlich recht einfach. Sie mal im Projektbereich nach. Da hab ich nen TWI-1Wire-Analyzer reingepackt. Der Anfang ist mit Assembler. Da wirst du Beispiele im Quellcode finden. In den Bemerkungen sieht man auch wie man sowas berechnet. Der Quellcode ist wegen der Länge in einer ZIP. Ist glaube ich so um den 22en Beitrag rum. Für eine Sekunde wirst du wohl schon (je nach Takt) bis zu 3 ineinandergelegte Schleifen benötigen.

Leg mal nen neuen Thread für die Aufgabe an.

Gruß
Dino
 
Hallo Severin,
ist es erlaubt, Deinen Quelltext auf Seite 1 zu kopieren ich würde diesen gern geistig
verarbeiten wollen.
Man kommt dadurch mit den Befehlen
z.B. ser temp enger in Kontakt.
Würde diesen auch gern mal debuggen.

Grüße

Rolf

he....bei AVR-Praxis geht ja richtig die Post ab!
 
Naja, strenggenommen sollte sich'ne Timer-Lösung ja auch mit diesen Befehlen erreichen lassen, selbst Interruptbasiert (I dann eben durch schreiben des ganzen SREG setzen) - oder braucht man dann hier I/O-Register, die IN/OUT nicht mehr erreichen?

EGAL

Ich denke auch, daß Hintergrund dieser Aufgabe das berechnen/planen von (Schleifen)Laufzeiten sein wird. Den wesentlichen Hinweis hat Dino ja bereits gegeben (Schleife , ggf geschachtelt).
Wichtig wäre jetzt noch die effektive Taktfrequenz des (simulierten) Prozessors.
Ein generelles Hilfsmittel sollte für Dich (neben dem vollständigen Datenblatt des verwendeten/simulierten Controllers) das " AVR-Instruction-Set" sein (da stehen auch die benötigten Takte aller Befehle drin), aber das werdet Ihr sicherlich schon haben...
Achso, der Faulenzer-Befehl für solche Schleifen heißt "NOP" - No Operation...

Aber Dino hat recht - das gehört alles in einen Neuen Thread...

viel Spaß weiterhin
LotadaC
 
Hallo Severin,

habe den Code mal durchgekaut und bin auf manche Befehle gestoßen,
mit den ich mich aus meinen schlauen Buch beschäftigen mußte.

Die angefügten Kommentare sind für später oft sehr hilfreich.
Man kann einfach die vielen Pseudobefehle brxx nicht im Kopf behalten.

Code:
; Projekt01 (mit Studio4)               06.10.2012

; Datei: severin01.asm

; AVR: Tiny2313-20PU

; erstellt von Severin am 02.10.2012
; zugefügte Kommentare u. geprüft von Rolf Hegewald.
; Build lief mit 0 Errors durch.
; für PORTA wurde PORTD gewählt.

.include "2313def.inc"
.def temp = R16
.def temp2 = R17

ser temp         ;setze alle Bits im Reg. r16
out DDRB, temp   ;Datenricht.von PORTB, OUTPUT
clr temp         ;lösche alle Bits von r16   

Einlesen:
	in temp, PIND   ;lade r16 mit Inhalt von PIND
 ldi temp2, 0    ;lade r17 alle 8Bits=LOW

Loop1:
	lsl temp        ;schiebe den Inh.r16 1x nach links
	                ;links heraus gesch.Bit8 gelangt in C-Flag
 brcs Loop2      ;Verzweigung nach Loop2, wenn C=1
	cpi temp, 0     ;vergleiche Inh. von r16 mit Konst.=0
	                ;r16=Konst. Z und C-Flag gesetzt
 breq Einlesen   ;Verzweigung nach Einlesen, wenn Z=1
	rjmp Loop1      ;springe nach Loop1, wenn Z=0

Loop2:
	inc temp2       ;+1 zum Inhalt von r17
	cpi temp2, 6    ;vergleiche Inhalt von r17 mit Konst.=6
	                ;r17=Konst. Z und C-Flag gesetzt
 brsh Ausgabe    ;Verzweigung nach Ausgabe, wenn C=1
	rjmp Loop1      ;springe nach Loop1, wenn C=0

Ausgabe:
	ldi temp, 1     ;lade r16 mit1
	out PORTB, temp ;Inhalt PORTB = 0b0000.0001
	clr temp        ;lösche alle Bits von r16
	rjmp Einlesen

Grüße

Rolf
 
evtl. Fehler?

Hallo Severin,
ich wollte Dir nur mitteilen, daß nach meiner Prüfung über den Debugger ein Fehler
im Quellcode vorhanden sein muß.

Also....ich habe nun bald 5x den Debugger ablaufen lassen, aber ich komme nicht
zur "Ausgabe:" an PORTB, egal welches Bit ich auf PIND setze.

Kann auch nicht wenn bei brsh Ausgabe das C-Flag auf 1 steht


Loop2:
inc temp2 ;+1 zum Inhalt von r17
cpi temp2, 6 ;vergleiche Inhalt von r17 mit Konst.=6
;r17=Konst. Z und C-Flag gesetzt
brsh Ausgabe ;Verzweigung nach Ausgabe, wenn C=0(steht auf 1!)
rjmp Loop1 ;springe nach Loop1, wenn C=1

oder habe ich einen Denkfehler? LotadaC wird es beurteilen können.

Grüße

Rolf
 
Du sollst auch nur zur Ausgabe kommen, wenn gleichzeitig (beim Einlesen) mindestens 6(!) Bits von PinD (im Original PinA) gesetzt waren. Deswegen ja der Vergleich (CP-compare) mit 6. Erst wenn der Registerinhalt (temp2) gleich oder höher (BRSH-Branch if same or higher), wird zur Ausgabe gesprungen. Höher kann er nicht werden, da er immer beim Erreichen von 6 (und der dann folgenden Ausgabe) zurückgesetzt wird (hinter der Sprungmarke einlesen).

P.S.: Du hast das [/QUOTE] verbummelt...

LotadaC
 
Nochwas:
rjmp Loop1 ;springe nach Loop1, wenn C=0 (muß 1 sein)
RJMP - Relative JuMP (relativer Sprung) ist ein ... äh ... unconditionaler (und relativer) Sprung. Also ohne Bedingung. Es wird immer gesprungen.
(relativ = relativ zum derzeitigen ProgrammCounter, Reichweite 4K words (2K in jede Richtung), aber die Berechnung aus dem aktuellen ProgrammCounter und der Zielmarke übernimmt der Assembler (kannst da natürlich auch selbst 'ne Zahl reinschreiben))

Hmm - langsam wirds hier OT. Ich hoffe, Severin nimmt uns das nicht übel...
 
Off Topic - vom Thema abweichen
(naja, wir weiten es ja genau genommen nur weiter aus. Und strenggenommen scheint Severin ja mit dieser Aufgabe fertig zu sein. Er hat eine, zugegebenermaßen etwas eigenwillige Lösung, aber es sollte ja auch seine eigene sein.)

@Severin: wenn Du Lust hast, kannst Du ja noch mal versuchen, Dinos (und meinen) Vorschlag zu implementieren, und durch den Simulator zu jagen. Als Zusatzaufgabe/Übung quasi...;)
 
Hi,

Sorry...was heist "OT"
OT oder O.T. oder OffTopic heißt das es langsam am ursprünglichen Thema vorbeigeht und abschweift.

Normalerweise sollte man beim Thema bleiben für das der Thread auch mal erstellt wurde. Ein wenig hin und her ist ja nicht weiter schlimm so lange man nicht auf einmal anfängt über den Einkauf für das nächste Grillen zu sprechen. Das was man schreibt sollte also möglichst noch irgendwas mit dem ursprünglichen Thema zu tun haben. Ein wenig abschweifen tut jeder mal.

ok, ich halte mich lieber aus allen raus!
Brauchst du nicht. Wenn es total am Thema vorbeigeht wird schon jemand was sagen oder ein Moderator einschreiten und notfalls den abschweifenden Teil in einen neuen Thread verschieben.

Wenn jetzt also zB jemand in diesem Thread anfängt über ein anderes Projekt zu reden dann wird er aufgefordert einen neuen Thread dafür aufzumachen. Da er den dan aufgemacht hat steht er auch als Starter für diesen Thread drin (ist für manche Sachen wichtig). Die abschweifenden Sachen werden dann in den neuen Thread verschoben und dann ist wieder alles schön sortiert :cool:

Im groben gehts ja noch um den Quellcode von Severin. Pendelt zwar etwas aber naja ...

Gruß
Dino
 
Ok, schmeiß ich mal was zum Thema rein (oder für Rolf: BTT - Back To Topic;)).
Das wäre meiner Meinung nach der Programmablaufplan von Severins letzter Version:
6-aus-8-zähler.png
(jaja, bei der letzten Verzweigung müßte das eigentlich andersrum stehen - carry gelöscht, und die Pfeile andersrum benannt - dann würde das auch zur entsprechenden bedingten Verzweigung (BRSH/BRCC) passen.
edit:
Mein erster Ansatz wäre dann so gewesen:
6-aus-8-zähler2.png
Der wesentliche Unterschied (abgesehen von der Zählrichtung) ist die Abbruchbedingung der Schiebeschleife. Bei mir terminiert die (bei weniger als 6 gesetzten bits) nach exakt 8 Durchläufen; bei Dir einen Durchlauf nach dem letzten herausgeschobenem Bit. Möglicherweise ist Dein Algorithmus damit im Durchschnitt schneller (also zB wenn gar keine Taste gedrückt wird).
"CLR temp" (vor loop1: ) und "cpi temp, 0" (danach) kannst Du weglassen.
Die erkannten Bits runterzuzählen (oder eben von 250 bis 0 hoch) würden auch hier ein CPI sparen.
 
Hi,


OT oder O.T. oder OffTopic heißt das es langsam am ursprünglichen Thema vorbeigeht und abschweift.

Normalerweise sollte man beim Thema bleiben für das der Thread auch mal erstellt wurde. Ein wenig hin und her ist ja nicht weiter schlimm so lange man nicht auf einmal anfängt über den Einkauf für das nächste Grillen zu sprechen. Das was man schreibt sollte also möglichst noch irgendwas mit dem ursprünglichen Thema zu tun haben. Ein wenig abschweifen tut jeder mal.


Gruß
Dino

tut mir leid, aber ich verstehe diesen Vorwurf nicht!
Hab aus Interesse den Quelltext von Severin durch den Debugger geschoben und mich
dabei vertan mit PORTA.
Habe zum Schluß noch betont "oder bei mir ein Denkfehler?"
D.h. ich bin doch bei der Sache geblieben...vom Grillen hab ich nichts geschrieben.
Nun antwortet bitte nicht mehr darauf, das Thema ist für mich durch!
 
Das mit dem OT bezog ich ja auch auf meine(!) "Kritik" an Deinem Kommentar im Code; deswegen stands ja auch direkt dahinter...
...RJMP - Relative JuMP (relativer Sprung) ist ein ... äh ... unconditionaler (und relativer) Sprung. Also ohne Bedingung...
... und natürlich kannst Du im Code kommentieren was Du willst - ich hatte lediglich befürchtet(!), daß Du das mit dem RJMP falsch interpretiert hast (eben weil er unbedingt (ohne Bedingung) ist, bei Dir aber das Gegenteil im Kommentar steht)
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)