AVR MP3-Player mit ganz neuer Siemens S65-LCD-Bibliothek

Fotos von der GUI. :-)

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.

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"?

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.

>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!

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.

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.

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.

>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.

Lupin schrieb:
> dass das Projekt nix neues bietet

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

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.

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.

> 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

... 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

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)));
}

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

... 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 ).

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

...  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.

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

Gruß sb1337