• Hallo Zusammen, Aufgrund der aktuellen Situation setzten wir die Möglichkeit aus, sich mit Gmail zu registrieren. Wir bitten um Verständnis Das RCMP Team

Tech-Frage Atmega 328 Portregister Funktion

BAXL

Admin
Mitarbeiter
Hallo Kollegen,

ich wusel schon eine ganze Zeit damit herum, warum beim Arduino die Portmanipulation über mehrere Write-Befehle länger dauert, als dem Port auf einem Rutsch den Portstatus für alle Ausgänge zu servieren.
Ich bin mir nicht sicher, wie die CPU den Port-Registern die Information übermittelt. Wird an den internen Portbaustein der Inhalt parallel als ein Wort übergeben, oder wird das Datum seriell in ein Schieberegister gebracht. Also je CPU-Takt ein Portstatus. Ich will darauf hinaus, ob bei der Portmanipulation der neue Portzustand mit einem CPU-Takt übergeben wird, oder seriell quasi mit 8 CPU-Takten.

Das würde dann auch erklären, warum es so viel länger dauert einen kompletten Port (8 Ausgänge) einzeln mit dem write-Befehl zu übergeben, weil dann ja quasi 8x8 CPU-Takte nötig wären und bei dem direkten Portbefehl nur 8 CPU-Takte. Aus dem Blockschaltbild werde ich nicht ganz schlau, ob der Databus 8 Bits parallel transportiert, oder ob das auch nur eine serielle Kommunikation ist.

Ich hoffe man kann verstehen was ich meine.



@BlackbirdXL1 @DFENCE
 

BAXL

Admin
Mitarbeiter
Ich war zwischenzeitlich nicht faul und habe weitergesucht. Nach folgendem Blockschaltbild sieht es mir so aus, als würden die internen Portbausteine die Daten seriell übergeben bekommen.
 
D

Deleted member 1492

Gast
Das direkte manipulieren der Ports ist hier gut beschrieben, es ist etwa 50mal schneller als die konventionelle Methode: Port-Manipulation
 

BAXL

Admin
Mitarbeiter
Sowas habe ich zuhauf gefunden. Dass das so ist, weiß ich mittlerweile, ich will verstehen warum das so ist. :)
Und dafür würde ich gerne wissen, wie das im Controller intern abläuft.
 
D

Deleted member 1492

Gast
Weil der Prozessor direkten Zugriff hat, ohne unnötige Umwege bzw. Rechenleistung.
 

BAXL

Admin
Mitarbeiter
Wie gelangen die Bits denn in den Portbaustein, seriell bittweise oder parallel als ein Byte.
 

BAXL

Admin
Mitarbeiter
Als Gedankenstütze

 
Zuletzt bearbeitet:

yoshi

Betreiber
Mitarbeiter
Die dicken Pfeile in den Diagrammen sind 8bit breite, parallele Datenbusse. Im ATmega werkeln also drei dieser Busse. Einer für die ganze periphere Hardware, einer für den Flash, in dem sich Programmcode und Bootloader verstecken und einer für den RAM.

In einem Prozessortakt können also 8 Bit zwischen CPU und peripherer Hardware, zwischen CPU und Flash und zwischen CPU und RAM verschoben werden. Lesen oder Schreiben ist dabei egal.


Um zu verstehen wie viele Takte die CPU für einen Befehl mindestens benötigt, müsst ihr aufhören in Arduino zu denken. Denn der Code der Arduino-IDE schleppt extrem viel Ballast mit sich, also unnötigen Code. C ist da schon besser. Die wirklichen Befehle und ihre benötigten Takte entscheiden sich über die Anzahl an Befehlen in Assembler (A). In jedem vollständigen Datenblatt eines ATmega wird irgendwo aufgeführt, wie viele CPU-Takte für welchen Befehl (A) benötigt werden. Die meisten Befehle (A) benötigen nur einen Takt. Ein Befehl (C) in C kann aber mehrere Befehle (A) in Assembler beinhalten. Auch C schleppt da ein paar unnötige Codezeilen in Assembler mit sich. In der einen Situation werden diese Zeilen benötigt, in der anderen nicht.

Am effektivsten wäre also eine direkte Programmierung in Assembler. Das kann ich aber nicht empfehlen. Viele Möglichkeiten in C muss man in Assembler selber erschaffen. Assembler kennt in dem Sinne keine Schleifenfunktion. Die muss selber geschrieben werden. Und die Fehlersuche in Assembler ist echt zum Kotzen.
 
Top Bottom