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