Hallo, ich habe schon mehrere kleinere µC-Projekte gemacht, aber nun scheitert's. Ich brauche folgendes: Einen Datei wird von SD-Karte gelesen und jedes Byte wird bitweise (0..7) auf einen Pin ausgegeben. Mein problem ist aber, dass jede Zustandwechsel genau 25µS dauern muss (4KHz). Ich habe bis jetzt noch nie so richtig Interrupts benutzt, aber nun geht nicht mehr ohne. Kann mir jemand ein Paar theoretische Tipps geben, wie sowas gemacht wird? Wie gesagt, Datenstrom am Ausgangspin soll ununterbrochen mit 4KHz folgen. MfG
Tim schrieb: > jede Zustandwechsel genau 25µS dauern muss (4KHz). Zustandswechsel? Bist du hier wirklich bandbegrenzt? Oder meintest du jede Bitzeit? Genau? Wie genau? Tim schrieb: > Kann mir jemand ein Paar theoretische Tipps geben, wie sowas > gemacht wird? Wie gesagt, Datenstrom am Ausgangspin soll > ununterbrochen mit 4KHz folgen. Brauchst du nur den einen Pin? Dann am besten mal den UART bemühen, vielleicht geht das. Oder den SPI. Ansonsten bitbanging im Timer Interrupt? Was für einen Mikrocontroller hast du da überhaupt?
Tim schrieb: > Ich habe bis jetzt noch nie so richtig Interrupts benutzt, > aber nun geht nicht mehr ohne. > Kann mir jemand ein Paar theoretische Tipps geben, wie sowas > gemacht wird? Wie gesagt, Datenstrom am Ausgangspin soll > ununterbrochen mit 4KHz folgen. einfach einen Timer verwenden der mit 4KHz aufgerufen wird und beim "Event" ein wert Rausschreiben.
>Guest schrieb: >Ansonsten bitbanging im Timer Peter II schrieb: > einfach einen Timer verwenden der mit 4KHz aufgerufen wird und beim > "Event" ein wert Rausschreiben. Genau das brauche ich > Interrupt? Was für einen Mikrocontroller hast du da überhaupt? PIC24 Mein Puffer beim Lesen von SD-Karte ist 256 Bytes gross. Wenn der leer wird, muss Datei weitergelesen werden, was natürlich ein wenig dauert. Brauche ich einen zweiten Puffer?
@Tim (Gast) >> einfach einen Timer verwenden der mit 4KHz aufgerufen wird und beim >> "Event" ein wert Rausschreiben. >Genau das brauche ich Dann tu es doch einfach, siehe Interrupt. Ist beim PIC sehr ähnlich. >Mein Puffer beim Lesen von SD-Karte ist 256 Bytes gross. Wenn der leer >wird, muss Datei weitergelesen werden, was natürlich ein wenig dauert. >Brauche ich einen zweiten Puffer? Wahrscheinlich schon, denn der Zugriff auf die SD-karte dauert ganz sicher länger als 25us. Man brauch ein FIFO in Software.
Tim schrieb: > Wie gesagt, Datenstrom am Ausgangspin soll > ununterbrochen mit 4KHz folgen. Das ist jetzt die Frage: 4 kHz oder 25 µs? Letzteres ist schon ein wenig anspruchsvoller, da muss man schon aufpassen dass die Interrupt-Routine so kurz wie möglich läuft. Ein USART im synchronen Modus, dass Byte für Byte mit 40 kBaud rausschiebt, wäre da entspannter, aber das hängt natürlich vom speziellen Prozessortyp ab. Bei einem normalen asynchronen UART stören Strat- und Stoppbits. Fazit: die Daten so gut vorbereiten, dass die 256 Bytes in der ISR mit wenigen Befehlen rausgetaktet werden können. Georg
Ich habe mich verschrieben, 250µS Periode ist richtig. Also 4KHz.
Tim schrieb: > Mein Puffer beim Lesen von SD-Karte ist 256 Bytes gross. Wenn der leer > wird, muss Datei weitergelesen werden, was natürlich ein wenig dauert. > Brauche ich einen zweiten Puffer? Da hätte ich mal 'ja' gesagt. Während der eine Buffer unter Timerkontrolle rausgetaktet wird, wird der 2.te Buffer von der SD-Karte gefüllt. Und so weiter, und so weiter. Nach Abarbeitung eiens Blocks, tauschen die beiden Buffer die Plätze. Während aus dem 2.ten rausgetaktet wird, wird der erste von der SD-Karte nachgefüllt. > Also 4KHz. D.h. der SD-Karten Code hat 64ms Zeit, um einen 256-Byte Block von der Karte zu lesen. Wenn das gewährleistet werden kann, dann seh ich kein Problem. D.h. solange der SD-Karten Code es verkraftet, wenn er mal (kurz) von einer Interrupt Routine unterbrochen wird.
Hallo, was mir so nebebei noch auffällt: 256 Bytes sind ein durchgehender Bit-Strom von 2048 Bit. Und das alles ohne Sicherung durch Prüfsumme, CRC o.ä.? Würde ich micht nicht trauen. Aber was heisst das schon, no risc no fun. Georg
Georg schrieb: > was mir so nebebei noch auffällt: 256 Bytes sind ein durchgehender > Bit-Strom von 2048 Bit. Und das alles ohne Sicherung durch Prüfsumme, > CRC o.ä.? Würde ich micht nicht trauen. Aber was heisst das schon, no > risc no fun. und was ist wenn die CRC falsch ist? Fehlerdialog anzeigen?
Peter II schrieb: > und was ist wenn die CRC falsch ist? Fehlerdialog anzeigen? Wo du recht hast hast du recht, es ist natürlich viel besser mit dem Fehler weiterzuarbeiten. Spart auch viel Aufwand, deshalb werden ja serielle Übertragungen auch niemals gesichert, das ist ja nur was für jämmerliche Weicheier. Georg
Georg schrieb: > Wo du recht hast hast du recht, es ist natürlich viel besser mit dem > Fehler weiterzuarbeiten. Spart auch viel Aufwand, deshalb werden ja > serielle Übertragungen auch niemals gesichert, das ist ja nur was für > jämmerliche Weicheier. wie wissen nicht was da hinten dran hängt, und wenn es nur ein RGB Strip ist? Auch kann es genauso gut möglich sein, das in den Daten schon die CRC mit enthalten ist.
Moin! Also, es wird mal ein Datasette-Emulator für einen C64. Klar, ich habe es sehr vereinfacht geschrieben. Es gibt noch start- und stop- bits, 0/1 wird anderes kodiert. In diesem Thread geht es nicht um CRC u.s.w. sondern um Algorithmus, wie sowas in einem µC programmiert wird... Ich habe bereits eine Art "Statemachine" in einem Timer-Interrupt gemacht. Vorher werden die Daten in einen 4Kb grosses Array gelesen und richtig ausgegeben. Das klappt schonmal! Nun werde ich mich mit Puffer/FIFO beschäftigen.
Tim schrieb: > Einen Datei wird von SD-Karte gelesen und jedes Byte wird > bitweise (0..7) auf einen Pin ausgegeben. Mein problem ist > aber, dass jede Zustandwechsel genau 25µS dauern muss (4KHz). Das schreit geradezu danach, das SPI zu benutzen. Das SPI muß allerdings einen Sendepuffer haben, damit keine Lücke entsteht. Z.B. die AVRs können die UART als SPI benutzen. Dann kann man auch den Baudratenteiler zum Einstellen der 4kBit benutzen. Interessant wäre, wozu man sowas ohne Takt gebrauchen könnte. Soll ein anderer MC das Signal empfangen, werden die irgendwann auseinander driften. Ohne zusätzlichen Takt oder Startbit ist da kein Blumentopf zu gewinnen. Das SPI liefert daher immer auch ein Taktsignal.
Tim schrieb: > Also, es wird mal ein Datasette-Emulator für einen C64. Das hättest du auch gleich sagen können. Dann ist nämlich klar, daß das Timing relativ entspannt ist. So ein Band "leiert" schließlich auch. Und der C64 (und andere Heimcomputer) kommen damit gut zurecht.
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.