mikrocontroller.net

Forum: Projekte & Code AVR MP3-Player mit ganz neuer Siemens S65-LCD-Bibliothek


Autor: sb1337 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ein Kollege und ich haben einen AVR-MP3-Player fertig gestellt.
Wir haben zudem eine neue Siemens-S65-LCD-Bibliothek komplett in C 
geschrieben, die ziemlich schnell ist und relativ viele Funktionen 
anbietet.
Passend dazu haben wir eine komfortable Oberfläche programmiert.

Projektseite: http://atmusic.my404.de
Dort findet man nötige Informationen, sowie Downloads des kompletten 
Quelltextes und der Dokumentationen.

Gruß, steffen1337

Autor: sb1337 (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Fotos von der GUI. :-)

Autor: daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sehr beeindruckend, wirklich klasse :)
ich werde dann schon mal 'ne bauteilbestellung auslösen...

ich verstehe nur eins nicht: die quasi nicht vorhandene resonanz auf 
dieses projekt.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was mir auffiel: beim Hangeln durch die verschiedenen Bildschirme wird 
die Musik (siehe video auf der obigen Seite) erheblich gestört. Woran 
liegt das? Könnt ihr das noch "abstellen"?

Autor: ABC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
super! welches s65 display verwendet ihr?
Soweit ich weiß gibt es ja 3 Typen. Funktioniert die Lib. mit allen S65 
Displays?

finde es gut, dass ihr alles so ausführlich dokumentiert habt.

Autor: andy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>ich verstehe nur eins nicht: die quasi nicht vorhandene resonanz auf
>dieses projekt.

na ja, ich kann mir das nur so erklären, dass man mittlerweile 
MP3-Player und S65 satt hat, ist halt ein alter Hut. Aber trotzdem, 
tolles Projekt!

Autor: daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ABC schrieb:
> welches s65 display verwendet ihr?
> Soweit ich weiß gibt es ja 3 Typen. Funktioniert die Lib. mit allen S65
> Displays?

in der studienarbeit steht, dass es um das display mit ls020xxx chip 
geht.

Autor: daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
andy schrieb:
> dass man mittlerweile
> MP3-Player und S65 satt hat

es geht doch bei bastelprojekten nur sehr selten primär um das resultat.
sonst würde ich mir einen mp3-player kaufen.

Autor: Lupin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich meine Andy meinte damit, dass das Projekt nix neues bietet. Du 
findest 100te Codes zur Ansteuerung von S65 Display und 1000de für 
VS10xx. Jetzt muss man nur aus beiden eins machen und fertig.

Autor: andy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich meine Andy meinte damit, dass das Projekt nix neues bietet. Du
>findest 100te Codes zur Ansteuerung von S65 Display und 1000de für
>VS10xx. Jetzt muss man nur aus beiden eins machen und fertig.

genau das meine ich. Mittlerweile sind viele Sachen zum Alltag geworden. 
Wenn hier einer schreibt, er würde ein neues TCP/IP-Stack 
entwickeln(habe ich heute morgen hier gelesen), schön, dass man sowas 
macht, man lernt auch eine ganze Menge dabei, schließlich gehts auch 
darum, dass man was neues dazu lernt, aber man wird damit niemanden mehr 
vom Hocker reißen.

Abgesehen davon, ist das ein tolles Projekt, schöne GUI, muss echt viel 
Zeit gekostet habe. Ich habe selbst ein S65 seit Jahren rumliegen, werde 
mal bei Gelegenheit die GUI ausprobieren.

Autor: daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lupin schrieb:
> dass das Projekt nix neues bietet

ich finde schon, dass die bibliothek zur ansteuerung des displays etwas 
neues bietet.

Autor: andy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
auch wenn viele Sachen mittlerweile zum Alltag gehören, lasst euch nicht 
davon abhalten eure Entwicklungen hier reinzustellen, bloß nicht. Es 
gibt immer noch Leute, die die erbrachte Leistung zu schätzen wissen.

Autor: andy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
muss mich Entschuldigen. Es wäre eine Schande das Projekt und "Bastelei" 
einzusortieren: Doku, Quellcode ... sieht ja sehr professionell aus. 
Wenn ich an meine Diplomarbeit von vor 7 Jahren denke, dann wirkt sie 
heute richtig lächerlich.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sb1337 schrieb:
> Projektseite: http://atmusic.my404.de
> Dort findet man nötige Informationen, sowie Downloads des kompletten
> Quelltextes und der Dokumentationen.

Hi Steffen,

da ich auch noch S65-Displays hier rumliegen habe, war deine Bibliothek 
willkommen, auch wenn es schon was gab. Das war nicht so "rund" wie 
deine.

Danke für dieses Projekt und auch Respekt vor der Studienarbeit. Macht 
einen guten Eindruck. Klasse.

900ss

Autor: sb1337 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> da ich auch noch S65-Displays hier rumliegen habe, war deine Bibliothek
> willkommen, auch wenn es schon was gab. Das war nicht so "rund" wie
> deine.

Die LCD-Bibliothek war hauptsächlich die Arbeit meines Kommilitonen. Er 
hat sich da schon mächtig ins Zeug gelegt. :-)


> Was mir auffiel: beim Hangeln durch die verschiedenen Bildschirme wird
> die Musik (siehe video auf der obigen Seite) erheblich gestört. Woran
> liegt das? Könnt ihr das noch "abstellen"?

Das liegt daran, dass das Löschen des Bildschirmes dadurch geschieht, 
dass wir zigtausende schwarze Pixel senden, da wir keinen Befehl zum 
Löschen des Bildschirminhaltes kennen. Ich hatte das Programm testweise 
mal so umgeschrieben, dass der VS1011 während des Löschen des 
Bildschirmes noch 40 mal mit Daten gefüttert wird, dann war das Hängen 
weg. Allerdings wurde dadurch wiederum der Bildaufbau langsamer.


MfG Steffen

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... Ich hatte das Programm testweise mal so umgeschrieben, dass der 
VS1011 während des Löschen des Bildschirmes noch 40 mal mit Daten 
gefüttert wird, dann war das Hängen weg. Allerdings wurde dadurch 
wiederum der Bildaufbau langsamer ...

Immerhin ist das eine Lösung. Vielleicht hat jemand eine Idee, wie das 
Problem geschickt umgangen werden kann

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine Möglichkeit Zeit zu "sparen" besteht darin, vor dem Übertragen des 
zu sendenden Bytes zu prüfen, ob die Schnittstelle frei ist. So ist es 
möglich unmittelbar mach dem Schreiben weiter zu arbeiten. Damit die 
Flags korrekt gesetzt werden muss die erste Übertragung ohne Abfrage 
erfolgen.


* @param [in] byte      The byte to send */
void lcd_sendByte(uint8_t byte)
{
  SPDR = byte;
    while (!(SPSR & (1 << SPIF)));
}

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man kann auch einfach das Senden der Daten an den MP3 Chip asynchron 
(Interruptgesteuert) und somit auch während des Displaylöschens 
machen...

Autor: sb1337 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

> Eine Möglichkeit Zeit zu "sparen" besteht darin, vor dem Übertragen des
> zu sendenden Bytes zu prüfen, ob die Schnittstelle frei ist. So ist es
> möglich unmittelbar mach dem Schreiben weiter zu arbeiten. Damit die
> Flags korrekt gesetzt werden muss die erste Übertragung ohne Abfrage
> erfolgen.

Das hatten wir auch kurzzeitig so drin und ich habe auch noch eine 
Version der LCD-Lib, wo es abgeändert ist, so alleine läuft das auch 
sehr gut. Allerdings muss man dann auch immer darauf achten, dass beim 
Togglen des RS-Pins und beim Wechsel der SPI-Slaves alles zuende 
übertragen wurde.

Probleme gab es jedoch im Zusammenspiel mit der verwendeten 
Roland-Riegel-SD-Lib, da man ja ständig zwischen allen Slaves wechseln 
muss. Da wir erst gegen Ende des Projektes auf die Idee gekommen sind, 
war es zu umständlich, so viel abzuändern, bzw. der 
Geschwindigkeitsunterschied war nicht bedeutend groß genug.

> Man kann auch einfach das Senden der Daten an den MP3 Chip asynchron
> (Interruptgesteuert) und somit auch während des Displaylöschens
> machen...

Ich hatte ihn anfangs interruptgesteuert gefüttert, sobald der VS1011 
Daten anfordert. Allerdings war der ATmega dann nahezu durchgehend in 
der Interruptroutine und die Oberfläche war kaum noch zu bedienen.

MfG sb1337

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... Ich hatte ihn anfangs interruptgesteuert gefüttert, sobald der 
VS1011 Daten anfordert. Allerdings war der ATmega dann nahezu 
durchgehend in der Interruptroutine und die Oberfläche war kaum noch zu 
bedienen ...

Wenn ich das Datenblatt des Chips richtig interpretieren, werden 32 
Bytes in einem Schwung übertragen. Bei 128 KBit = 16 KBytes sind das 512 
Interrupt pro Sekunde. Einen SPI-Takt von 4 MHz angenommen ist die 
CPU-Last bei 1 %
( 1 / 4 MHz  x 32 Bytes x 512 Interrupt x 2fachen Verwaltungsüberhang ).

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sb1337 schrieb:
> Ich hatte ihn anfangs interruptgesteuert gefüttert, sobald der VS1011
> Daten anfordert. Allerdings war der ATmega dann nahezu durchgehend in
> der Interruptroutine und die Oberfläche war kaum noch zu bedienen.
>
> MfG sb1337

So war das auch nicht gemeint. Immerhin musst du ja beim Senden von den 
32 Bytes warten, dass das eine Byte fertig ist, bevor du mit dem 
nächsten anfängst. Und warten ist einfach schlecht. Erst Recht in einer 
ISR.

Wie ist das denn, wenn du einfach nach dem Starten des Liedes den VS1011 
voll machst und dann alle 10ms (oder 1ms?) prüfst (Interrupt), ob der 
DREQ Pin aktiviert wurde UND ob die vorherige SPI-Transmission 
abgeschlossen ist. Ist das der Fall, sendest du das nächste Byte.

Alternativ geht auch ganz normal die Methode mit einem FIFO Buffer: 
Sobald ein SPI Byte rausgesendet wurde, wird ein Interrupt ausgelöst, du 
schaust nach, ob der DREQ Pin noch aktiviert ist und sendest das nächste 
Byte raus (im Hintergrund).

Bei beiden  Methoden läuft das Befüllen quasi im Hintergrund ab und du 
kannst mit Vollspeed ständig dein Display zutexten.
Dadurch, dass der SPI Kram immer periodisch in einer ISR gecheckt wird 
(ohne Warten!), hat dieser automatisch eine höhere Priorität als das LCD 
(was ja hoffentlich in der Main-Loop befüllt wird).

Einfach mal kreativ sein!

Autor: Sebastian ... (zahlenfreak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich schicke im Interrupt immer 32 Bytes auf einmal zum VS und warte im 
Interrupt auf die SPI. Wenn der VS danach noch mehr daten akzeptiert 
bekommt er die sogar auch sofort, ohne dass der Interrupt beendet wird. 
Auf die weise kann ich auch WAV-dateien (1411kbit/s) abspielen und 
nebenbei noch ein Menü und displayaufbau abhandeln. Bei mp3-dateien 
langweilt sich mein AVR zu tode. Irgendwas musst du also falsch gemacht 
haben. Mehr als 10% CPU-last kann mp3 abspielen ja nicht erzeugt haben, 
sonst ginge WAV bei mir nicht.

Sebastian

Autor: sb1337 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!
Vielen Dank für die vielen Antworten und Tipps an Alle!

> Irgendwas musst du also falsch gemacht
> haben. Mehr als 10% CPU-last kann mp3 abspielen ja nicht erzeugt haben,
> sonst ginge WAV bei mir nicht.

Ja, da hast du wohl Recht. Hatte es auch nur mal ganz kurz mit 
Interrupts getestet und da ist mir dann sicher irgendwo ein Fehler 
unterlaufen. Also hier und da bietet der Code sicher noch 
Tuningmöglichkeiten und das kleine Hängen beim Löschen des Bildschirmes 
würde man sicher auch noch wegbekommen. Aber ich benötige jetzt erst mal 
ein wenig Pause vom ATmega, da dieses neben kleinen Basteleien mein 
erstes Projekt war und mich als Quasieinsteiger doch schon recht gut 
gefordert hat. ;-)

MfG sb1337

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sebastian ... schrieb:
> Ich schicke im Interrupt immer 32 Bytes auf einmal zum VS und warte im
> Interrupt auf die SPI. Wenn der VS danach noch mehr daten akzeptiert
> bekommt er die sogar auch sofort, ohne dass der Interrupt beendet wird.

Das ist aber die schlechteste Variante überhaupt. Denn der Interrupt 
kann lange dauern, bis der Buffer von ganz leer aufgefüllt wurde. 
Während dieser Zeit kann der AVR NICHTS anderes mehr machen. Man sollte 
den Ladeprozess feiner zerteilen, wie ich oben beschrieb.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...  Man sollte den Ladeprozess feiner zerteilen, wie ich oben beschrieb 
...

Dabei nicht vergessen, die Daten von der SD-Card zu lesen. Nebenbei: 
alle drei (LCD, SD-Card, VS) hängen an der gleichen SPI-Schnittstelle.

Autor: Sebastian ... (zahlenfreak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das ist aber die schlechteste Variante überhaupt. Denn der Interrupt
> kann lange dauern, bis der Buffer von ganz leer aufgefüllt wurde.
> Während dieser Zeit kann der AVR NICHTS anderes mehr machen. Man sollte
> den Ladeprozess feiner zerteilen, wie ich oben beschrieb.

Ich weiß, aber die Variante lief erstmal und hat bisher keine Probleme 
gemacht. Der VS-Puffer muss sowieso nur komplett gefüllt werden, wenn 
die Wiedergabe neu gestartet wurde. In einer Situation also, wo der 
Nutzer normalerweise eh nichts bedienen will. Der Interne Puffer ist da 
auch ganz gut gefüllt, weil mindestens ein Cluster im RAM liegt. 
Außerdem taktet der SPI auf 4MHz, um die 2kByte puffer des VS zu füllen 
brauch ich also eh nur 4ms (wenn ich mich nicht verrechnet habe)
Sicher ist das alles andere als Optimal, aber ich hab noch genug andere 
Baustellen, die mir dringender sind. Denn Ich hab weder unterbrechungen 
in der Musik noch reagiert das Menü langsam.

Sebastian

Autor: sb1337 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Website ist jetzt nur noch über
http://www.my404.de
zu erreichen, die Subdomain atmusic. existiert nicht mehr.

Gruß sb1337

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.