Tipps zur Aufgabe 1

[Ravu al Hemio]

Ich hab mir nach manch einem Problem mit dem GLCD gedacht, es wär ganz nützlich, eine allgemeine Sammelstelle für Tips zur ersten Aufgabe zu haben, also mache ich diesen Thread auf.

Wer selbst Tipps hat, möge ebenfalls zu diesem Thread beitragen.

HAL-GLCD und GLCD

• Es ist verdammt einfach, RST (PE7) unabsichtlich auf low (0) zu setzen. Falls sich das Display nicht einmal ansatzweise korrekt verhält, könnte das die Ursache sein.
• Wenn Daten ("welche Pixel sind gesetzt?") vom GLCD ausgelesen werden, muss der Befehl zweimal geschickt werden, da Sinnvolles erst beim zweiten Mal kommt. (Das Auslesen des Status ist hiervon nicht betroffen.)
• Die Zeichen der Schriftart für den GLCD sind im Flash gespeichert. Darauf muss man über einen Umweg zugreifen, da die Adresse 1234 im data space etwas anderes bedeutet als die Adresse 1234 im program space. (Mögen Harvard-Architekturen baldigst aussterben.)

SPI

• Wegen der Shift-Register-Natur von SPI ist es notwendig, beim Lesen den Wert 0xFF in den Register hineinzuschreiben, damit "auch etwas kommt".

ADC

• Zum Triggern des ADC mit Hilfe eines Timers (z.B. Timer 1) sollte dieser in den CTC-Mode gesetzt werden. Dann muss man sowohl OCR1A ("wann soll der Counter wieder bei 0 anfangen") und OCR1B ("wann soll der ADC getriggert werden") auf denselben Wert einstellen. Im ADC-Interrupt-Handler müssen dann die Flags OCF1B und ADIF auf 1 gesetzt werden.

Kompilieren/Linken

• Um eine weitläufige Dead-Code-Eliminierung durchführen zu lassen, kann man dem Compiler die Flags -ffunction-sections -fdata-sections und dem Linker --gc-sections übergeben. Falls man den Linker nicht direkt mit avr-ld sondern mit avr-gcc aufruft, lautet die Syntax -Wl,--gc-sections.

(weitere Kategorien folgen)

[bbernhard1]

Ich hab zwar keine Tipps, hätte aber eine Frage an alle jene, die sich schon mit der GLCD Ansteuerung beschäftigt haben. Und zwar geht es um folgendes: Bei der Ansteuerung des GLCDs muss man ja penibel genau auf die im Datenblatt angegebenen Timings achten. In der Spezifikation steht, dass man für die wenigen Nanosekunden, die man warten muss, ein (oder mehrere) NOPs verwenden kann. Nur wie berechne ich die Anzahl der NOPs? Soll ich mir dazu anschauen, welchen Assemblercode der Compiler draus macht und dann ggf. NOPs hinzufügen, oder wie macht ihr das?

Um es mal an einem Beispiel zu erläutern: Im Datenblatt steht, dass die Enable Leitung beim Schreibvorgang für mind. 450ns auf Low sein muss. In meiner Routine wird also als erstes die Enable Leitung auf Low gezogen, dann werden die Zustände auf den restlichen Leitungen (CS1, CS2..usw) eingestellt, und dann zieh ich die Enable Leitung wieder auf High. Als nächstes hab ich mir angesehen, was der Compiler draus macht (Assemblercode). Wenn ich die Zyklen, die die einzelnen Instruktionen benötigen, aufaddiere, dann komm ich auf mehr als 450ns. Ich würde demnach kein NOP benötigen. Nur was würde passieren, wenn ich beim Compiler Optimierungen einstelle? Dann könnte der ja etwas wegoptimieren und mein Timing würde dann nicht mehr stimmen?
Wie programmiert man solche zeitkritischen Routinen am besten? Komplett in Assembler, ein Misch-Masch aus C und Assembler...oder..?

[anwesender]

(Mögen Harvard-Architekturen baldigst aussterben.)

für die software engineerer gibts zum glück java, CIL, python und co


DSPs sind hald doch immer noch ein schönes beispiel für harvard architekturen.

für mind. 450ns auf Low sein muss.

Wie programmiert man solche zeitkritischen Routinen am besten?

naja, es steht ja zum glück mindestens und nicht maximal, das würd ich in dem fall nicht als zeitkritisch sehen
also mein glcd treiber ist komplett in C.

zum thema compiler-optimierungen, es gibt ja noch gcc -S, damit lässt sich das ja sehr gut überprüfen.
wieviele nops man braucht, ausrechnen! wieviele cycles braucht ein nop, wie lang dauert ein cycle bei einem 16MHz quartz,
wie siehts theoretisch mit dem pipelining aus (verändert das die anzahl nops?), daraus lässt sich alles schön berechnen.

Thomas

[Ravu al Hemio]

Bitte diesen Thread nicht zweckentfremden. (Bislang hat sich kein Moderator dazu durchgerungen, den Thread entsprechend aufzuteilen, und ich wollte nicht auf bbernhard1s Frage antworten, bis das passiert ist.)

[_kassiopeia_]

Wenn das GLCD nach Ein-/Ausschalten des Board zuerst richtig funktioniert, nach ein paar mal Reset drücken aber nicht mehr zu reagieren scheint, kann es helfen einen Pull Down auf PE7 zu verwenden (der Reset Kanal des GLCD).

[bbernhard1]

Bitte diesen Thread nicht zweckentfremden. (Bislang hat sich kein Moderator dazu durchgerungen, den Thread entsprechend aufzuteilen, und ich wollte nicht auf bbernhard1s Frage antworten, bis das passiert ist.)

Zum MP3-Modul:

Wenn ihr den Sinustest macht, dann übergebt der mp3SetVolume() Funktion mindestens einen Wert von ca. 170 (dezimal). Alles andere hört man nicht...oder ich bin einfach schon viel zu hörgeschädigt

@Ravu al Hemio: Sorry, ich dachte man kann in dem Thread auch Fragen stellen.

@anwesender: Danke, dann werd ich's auch mal komplett in C probieren.

[qwerty]

Noch ein Tipp zum Mp3-Modul.

Bei mir hats am Anfang nur knackende Geräusche erzeugt bei aufrufen der mp3Init...

Sache bei mir zu Haus ist die folgende: Das Modul braucht bei der Init plötzlich bis zu 400mA(!) Strom, das gibt mein USB-Port seltsamerweise nicht mehr her, die Spannung sinkt auf unter 4.3V und der standartmäßig-aktivierte Brownout-Detector des mega1280 zieht auf reset!

[Drunken]

Zum sdCard-Modul:

Die neueste Version (2.0) des Moduls arbeitet nicht mehr mit BLOCK, sondern mit BYTE-Adressen, d.h. KEINE Division der Adressen aus sdcardIndex.txt durch 32 erforderlich!