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
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.
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
> 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)));
}
Man kann auch einfach das Senden der Daten an den MP3 Chip asynchron (Interruptgesteuert) und somit auch während des Displaylöschens machen...
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 ).
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!
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
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
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.
... 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.
> 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
Die Website ist jetzt nur noch über http://www.my404.de zu erreichen, die Subdomain atmusic. existiert nicht mehr. Gruß sb1337
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.