Results 1 to 32 of 32

Thread: Fragen zur SD-Card Library

  1. #1
    Baccalaureus bbernhard1's Avatar
    Join Date
    Mar 2010
    Posts
    772
    Thanks
    61
    Thanked 157 Times in 80 Posts

    Fragen zur SD-Card Library

    Hi,

    ich hätte ein paar Fragen zur SD-Card Library:

    .) Man kann ja sowohl die vorkompilierte Library, als auch den Sourcecode downloaden. Unterscheiden sich die beiden in ihrer Funktion? Ich frage deshalb, weil in der Spezifikation steht: "The library handles the chip-select signals of the SPI access and before it accesses the card, it checks if it is really inserted." Wenn ich jedoch in der Funktion sdcardReadBlock() nachsehe, dann finde ich die Überprüfung, ob die Karte tatsächlich eingelegt ist, nicht...Oder überseh ich da was?

    .) Kann es sein, dass die Funktion
    Code:
    bool sdcardAvailable() {
        return ((SDCARD_PIN & SDCARD_CD) == 0) ? false : true;
    }
    falsch ist? Ich bin zwar gerade nicht im Labor, und kann das daher nur mit dem Connector, welcher direkt am bigAVR verbaut ist, testen - doch da liefert die Funktion falsche Werte.

    Sollte das nicht eher so lauten:
    Code:
    bool sdcardAvailable() {
        return ((SDCARD_PIN & (1<<SDCARD_CD))) ? false : true;
    }
    ?

  2. #2
    Master
    Join Date
    Oct 2007
    Posts
    117
    Thanks
    6
    Thanked 11 Times in 11 Posts
    Quote Originally Posted by bbernhard1 View Post
    Unterscheiden sich die beiden in ihrer Funktion? ... "The library handles the chip-select signals of the SPI access and before it accesses the card, it checks if it is really inserted."
    Die Sourcen und die kompilierten packages unterscheiden sich nicht. Da weicht die Implementierung von der Spec ab...

    Quote Originally Posted by bbernhard1 View Post
    Kann es sein, dass die Funktion
    Code:
    bool sdcardAvailable() {
        return ((SDCARD_PIN & SDCARD_CD) == 0) ? false : true;
    }
    falsch ist? ...
    Sollte das nicht eher so lauten:
    Code:
    bool sdcardAvailable() {
        return ((SDCARD_PIN & (1<<SDCARD_CD))) ? false : true;
    }
    ?
    Ja, das ist ein Fehler und wird ausgebessert (nach Ostern). Danke!

  3. The Following User Says Thank You to novice For This Useful Post:


  4. #3
    Principal
    Join Date
    Nov 2008
    Posts
    95
    Thanks
    13
    Thanked 4 Times in 4 Posts
    Hats schon jemand geschaft mit dem sdcardlibary oder mit dem Quellcode etwas zu machen? Ich bekomm bei beiden folgende Meldung:
    /usr/lib/gcc/avr/4.3.5/../../../avr/lib/avr51/crtm1280.o: In function `__bad_interrupt':
    ../../../../crt1/gcrt1.S:193: undefined reference to `main'
    make: *** [sdcard.elf] Error 1

  5. #4
    Master
    Join Date
    Oct 2007
    Posts
    117
    Thanks
    6
    Thanked 11 Times in 11 Posts
    Die Library beinhaltet keine main() Funktion. Du musst selbst noch eine Applikation schreiben, die die Funktionen in der lib verwendet.

  6. #5
    Baccalaureus bbernhard1's Avatar
    Join Date
    Mar 2010
    Posts
    772
    Thanks
    61
    Thanked 157 Times in 80 Posts
    Hat von euch schon jemand die SD-Card Library erfolgreich zum Laufen bekommen? Irgendwie klappt das bei mir mit dem Lesen von der SD-Karte nicht so ganz. Wenn ich das Debugging aktiviere, dann bekomm ich die Fehlermeldung "wait on data failed". An den SPI Funktionen kanns ja nicht liegen, sonst würd der ja schon bei Ausführung der sdcardInit() schreien, oder? Da beim MP3 Modul die Ausgabe des Sinustestsignal funktioniert, muss ja theoretisch zumindest spiInit() und spiSend() richtig implementiert sein. Mein spiReceive() sieht übrigens so aus, dass ich ein Dummy-Byte (0xFF) sende und dann etwas vom SPI Bus lese.

    Hat jemand nen Tipp, was da bei mir schief läuft?

  7. #6
    Elite maciej's Avatar
    Join Date
    Dec 2009
    Posts
    257
    Thanks
    34
    Thanked 39 Times in 34 Posts
    Quote Originally Posted by bbernhard1 View Post
    Hat von euch schon jemand die SD-Card Library erfolgreich zum Laufen bekommen? Irgendwie klappt das bei mir mit dem Lesen von der SD-Karte nicht so ganz. Wenn ich das Debugging aktiviere, dann bekomm ich die Fehlermeldung "wait on data failed". An den SPI Funktionen kanns ja nicht liegen, sonst würd der ja schon bei Ausführung der sdcardInit() schreien, oder? Da beim MP3 Modul die Ausgabe des Sinustestsignal funktioniert, muss ja theoretisch zumindest spiInit() und spiSend() richtig implementiert sein. Mein spiReceive() sieht übrigens so aus, dass ich ein Dummy-Byte (0xFF) sende und dann etwas vom SPI Bus lese.

    Hat jemand nen Tipp, was da bei mir schief läuft?
    Ich hab leider keinen Tipp, aber krieg beim initialisieren und auch beim lesen ein E_TIMEOUT. Bin derzeit auf einer (bis jetzt erfolglosen) Fehlersuche.

  8. #7
    Baccalaureus bbernhard1's Avatar
    Join Date
    Mar 2010
    Posts
    772
    Thanks
    61
    Thanked 157 Times in 80 Posts
    Quote Originally Posted by maciej View Post
    Ich hab leider keinen Tipp, aber krieg beim initialisieren und auch beim lesen ein E_TIMEOUT. Bin derzeit auf einer (bis jetzt erfolglosen) Fehlersuche.
    Ok, dann bin ich wenigstens nicht alleine. Hast du schon mal bei eingeschaltetem Debugging geschaut, wo er genau bei dir hängt?

  9. #8
    Principal
    Join Date
    Nov 2008
    Posts
    95
    Thanks
    13
    Thanked 4 Times in 4 Posts
    Quote Originally Posted by bbernhard1 View Post
    wo er genau bei dir hängt?
    Bei mir hings bei sdcardInit, weil meine im spInit gesetzten Werte am PortB(SDCARD_DDR) von diesen wieder ueberschrieben wurden, hab daher das in spiSend nochmal eingabaut, jetzt haengst beim ersten spiRecive (SPIF wird wohl nie gesetzt ) in sdcardReadBlock bei waitOnNot. Hab ich ueber Leds rausgefunden. Wie funktioniert debug ?
    Last edited by zool; 10-04-2012 at 18:35.

  10. #9
    Elite maciej's Avatar
    Join Date
    Dec 2009
    Posts
    257
    Thanks
    34
    Thanked 39 Times in 34 Posts
    Quote Originally Posted by bbernhard1 View Post
    Ok, dann bin ich wenigstens nicht alleine. Hast du schon mal bei eingeschaltetem Debugging geschaut, wo er genau bei dir hängt?
    Wenn ich den Debug output am bildschirm ausgebe sagt er mir "app failed". Gibts irgendwo das datasheet für das ansprechen der sd-karte?
    Last edited by maciej; 10-04-2012 at 20:03. Reason: frage nach falschem datasheet

  11. #10
    Baccalaureus bbernhard1's Avatar
    Join Date
    Mar 2010
    Posts
    772
    Thanks
    61
    Thanked 157 Times in 80 Posts
    Quote Originally Posted by maciej View Post
    Wenn ich den Debug output am bildschirm ausgebe sagt er mir "app failed". Gibts irgendwo das datasheet für das ansprechen der sd-karte?
    Hmm, komisch - bei mir schreit er da noch nicht. Verwendest du deine eigene SD-Karte zum Testen, oder die aus dem Labor?

    Datenblatt hab ich keines, aber hier[1] steht viel interessantes.

    @zool: Ich weiß nicht, ob das mit der vorkompilierten Library auch geht, aber bei den Sourcen aktivierst du mit #define DEBUG den Debugmodus (im sdcard.c File). Damit das funktioniert, musst du aber noch einen der beiden UARTs (UART1 oder UART2) initialisieren und stdout entsprechend umleiten.

    [1] http://elm-chan.org/docs/mmc/mmc_e.html

    edit: Statt der SD-Karte vom Labor, hab ich jetzt testweise mal meine eigene SD Karte verwendet. Wenn ich nun sdcardReadBlock() ausführe, dann bekomme ich zumindest mal keine Fehlermeldung. Doch die Daten, die ich lese, stimmen irgenwie nicht mit denen überein, die ich erwarte. Wenn ich die SD-Karte mit nem Hex-Editor öffne, dann kann ich mir ja ansehen was in den einzelnen Sektoren steht. Wenn ich das nun mit dem vergleiche, was ich lese, dann stimmt das nicht überein...
    Last edited by bbernhard1; 10-04-2012 at 22:06.

  12. #11
    Principal
    Join Date
    Nov 2008
    Posts
    95
    Thanks
    13
    Thanked 4 Times in 4 Posts
    Quote Originally Posted by bbernhard1 View Post
    aber bei den Sourcen aktivierst du mit #define DEBUG den Debugmodus (im sdcard.c File). Damit das funktioniert, musst du aber noch einen der beiden UARTs (UART1 oder UART2) initialisieren und stdout entsprechend umleiten.
    Fuer Uart hab ich den Code von der HTL ausgegraben, der Teil ist kein Problem aber, wie leit ich den stdout zum uart um ? Oder geht da nur Stueck fuer Stueck selbst schreiben. (hab eigentlich an Linux gedacht, wo das ja mit einem Befehl geht)

  13. #12
    Baccalaureus bbernhard1's Avatar
    Join Date
    Mar 2010
    Posts
    772
    Thanks
    61
    Thanked 157 Times in 80 Posts
    Quote Originally Posted by zool View Post
    Fuer Uart hab ich den Code von der HTL ausgegraben, der Teil ist kein Problem aber, wie leit ich den stdout zum uart um ? Oder geht da nur Stueck fuer Stueck selbst schreiben. (hab eigentlich an Linux gedacht, wo das ja mit einem Befehl geht)
    Das kannst du auch mit einem Befehl machen. Wie das genau funktioniert, steht im ersten Example-Code auf dieser[1] Seite.

    [1] http://www.nongnu.org/avr-libc/user-...vr__stdio.html

  14. #13
    Baccalaureus bbernhard1's Avatar
    Join Date
    Mar 2010
    Posts
    772
    Thanks
    61
    Thanked 157 Times in 80 Posts
    Sooo, ich hab mir jetzt mal aus dem Internet ne SD-Library gesucht und diese für den AVR angepasst. Doch auch damit funktioniert's nicht...Die gelesenen Daten stimmen einfach nicht mit den erwarteten Daten überein. Komisch ist auch: Wenn ich mehrmals hintereinander von der gleichen Adresse lese, dann bekomm ich immer unterschiedliche Daten und das, obwohl laut Return-Wert kein Fehler beim Lesevorgang aufgetreten ist....
    Meine SD-Karte (vom Hersteller "Traveler") hab ich auch schon mal neu formatiert, doch das änderte auch nichts dran. Morgen werd ich zum Testen noch ne andere SD-Karte verwenden. Aber langsam gehn mir echt die Ideen aus...

  15. #14
    Elite maciej's Avatar
    Join Date
    Dec 2009
    Posts
    257
    Thanks
    34
    Thanked 39 Times in 34 Posts
    for the record: bei mir war der fehler das ich beim empfangen über spi als dummy byte 0x00 genommen habe. mit einem dummy byte von 0xFF funktioniert es klaglos.

  16. #15
    Baccalaureus bbernhard1's Avatar
    Join Date
    Mar 2010
    Posts
    772
    Thanks
    61
    Thanked 157 Times in 80 Posts
    Quote Originally Posted by maciej View Post
    for the record: bei mir war der fehler das ich beim empfangen über spi als dummy byte 0x00 genommen habe. mit einem dummy byte von 0xFF funktioniert es klaglos.
    Hmm, das hätte ich eigentlich eh. Komisch..

    edit: Jetzt funktionierts bei mir auch. Hab aber eigentlich nichts geändert

    Egal, Hauptsache es funktioniert
    Last edited by bbernhard1; 12-04-2012 at 00:07.

  17. #16
    Master qwerty's Avatar
    Join Date
    Mar 2012
    Posts
    120
    Thanks
    8
    Thanked 19 Times in 14 Posts
    Wie muss die Karte denn eigentlich formatiert sein? Ich hab hier eine SanDisk Extreme 8GB (FAT32) und ich krieg auf
    den rst-command 0x01 zurück (das dürfte iO sein), auf app dann 0xF0 und sendOpCond 0xFC, ab dann loop'd das ganze dann weil opCond != 0x00 und dann krieg ich nur mehr wiederholt app: 0x05 und sendOpcond: 0xE1 zurück.

    wie war die Vorgangsweise bei den Leuten die's hingekriegt haben (wie, wo formatiert; womit das image geschrieben?)

    Vielen Dank, Chris.

  18. #17
    Baccalaureus bbernhard1's Avatar
    Join Date
    Mar 2010
    Posts
    772
    Thanks
    61
    Thanked 157 Times in 80 Posts
    Quote Originally Posted by qwerty View Post
    Wie muss die Karte denn eigentlich formatiert sein? Ich hab hier eine SanDisk Extreme 8GB (FAT32) und ich krieg auf
    den rst-command 0x01 zurück (das dürfte iO sein), auf app dann 0xF0 und sendOpCond 0xFC, ab dann loop'd das ganze dann weil opCond != 0x00 und dann krieg ich nur mehr wiederholt app: 0x05 und sendOpcond: 0xE1 zurück.

    wie war die Vorgangsweise bei den Leuten die's hingekriegt haben (wie, wo formatiert; womit das image geschrieben?)

    Vielen Dank, Chris.
    Welches Image meinst du denn?

    Eigentlich ist das Filesystem egal, da die Funktionen der SD-Card Library die Daten ganz plump "raw" lesen. Zum ersten Testen kannst du z.B. einfach ein File auf die SD-Karte spielen und dir dann in einem Hex-Editor ansehen, auf welcher Adresse die Daten liegen. Diese Adresse steuerst du dann mit dem uC an, und liest die Daten. Ich würd aber die SD-Karte vorher formatieren, sonst kanns dir passen, dass die einzelnen Segmente des Files nicht hintereinander, sondern irgendwie abgelegt werden.

  19. #18
    Master qwerty's Avatar
    Join Date
    Mar 2012
    Posts
    120
    Thanks
    8
    Thanked 19 Times in 14 Posts
    Stimmt natürlich, wenn ich da Raw draufschreibe ist der Rest wurst...

    Ich formatier jetzt die Karte mal komplett und werd zusätzlich noch mal eine 2testen.
    Mich verwundert bis jetzt die Antwort der Karte auf APP_CMD (CMD55) und APP_SEND_OP_COND ACMD41...

  20. #19
    Master qwerty's Avatar
    Join Date
    Mar 2012
    Posts
    120
    Thanks
    8
    Thanked 19 Times in 14 Posts
    Nope hat leider nix gebracht, auch mit der anderen Karte nicht... dort krieg ich nur gleich eine illegal cmd response (0x05) auf mein APP_CMD fck.
    Last edited by qwerty; 14-04-2012 at 22:04.

  21. #20
    Master qwerty's Avatar
    Join Date
    Mar 2012
    Posts
    120
    Thanks
    8
    Thanked 19 Times in 14 Posts
    sry doppelpost
    Last edited by qwerty; 14-04-2012 at 22:04.

  22. #21
    Master qwerty's Avatar
    Join Date
    Mar 2012
    Posts
    120
    Thanks
    8
    Thanked 19 Times in 14 Posts

    Wies bei mir wirklich gegangen ist

    Nun gut, es hat dann noch heute bis 04:30 gedauert, aber es klappt nun....


    Folgende Erkenntnisse wurden gewonnen:

    Die SdCard-Library is gut, aber von einigen fundamentalen Fehlern durchzogen:


    1. Der Reset-Routine läuft nicht nach Spec (nach dem reset CMD können auch andere Werte als 0xFF und 0x01 die rejected werden müssen. Viele Karten antworten mit teilweise gelöschten Flags in der R1 Antwort bevor sie in den idle state gehen, die lib lässt das dann schon als erfolgreiche Antwort durchgehen...)
    2. Jede einzelne Befehlsversand läuft nicht nach Spec (nach jedem gesendeten CMD sind nochmals mind 8 CLK Ticks notwendig, sprich zumindest 1 dummy byte um der karte zeit zu geben sich für den nächsten cmd vorzubereiten)
    3. die MMC-CS line sollte nach jeder Kommunikation de-asserted werden
    4. die ersten 74+ clock ticks zur Initialisierung dürfen nur max 400kHz SPI taktfrequenz (momentan F_OSC/4) haben. während dessen soll eigentlich MMC-CS hi sein (mom schon lo).
    5. es wird kein kartentyp geprüft, sprich es gibt nur eine reset routine. Alle ganz alten und viele älteren Karten brauchen CMD1 zum init und nicht ACMD41.
    6. SDCH funktioniert anderes als SD!!!!!!RufzeichenEins!!! War der längste game-breaker


    Zur mp3 lib:
    Sollte unbedingt in der Task-Spec besser formuliert werden werden: Den Decoder erstmalig solange mit Blöcken füttern bis mp3Busy == true dann ist nämlich DREQ auf Gnd gegangen und die ISR kann überhaupt getriggert werden (ISC0 = Rising edge of INT). In jedem interrupt muss dann wieder solange nachgeschaufelt werden bis PD0 lo!

    Dh Vorgangsweise kann sein:
    1. mp3Init
    2. INT0 interrupt flag clearen (1 reinschreiben)
    3. globales interrupt flag setzen
    4. sdcardreadblock
    5. sendmusic
    6. blockaddress++
    7. gehe zu 4 solange !mp3busy


    den rest macht die ISR (wieder 4. bis 7.)


    Hoffe anderen gehelft zu haben,
    Chris


    PS: BockAddress ist ByteAddress/32 (wer sich wunder wenn nix oder nur schmarrn rauskommt

  23. #22
    Baccalaureus bbernhard1's Avatar
    Join Date
    Mar 2010
    Posts
    772
    Thanks
    61
    Thanked 157 Times in 80 Posts
    Quote Originally Posted by qwerty View Post
    Nun gut, es hat dann noch heute bis 04:30 gedauert, aber es klappt nun....


    Folgende Erkenntnisse wurden gewonnen:

    Die SdCard-Library is gut, aber von einigen fundamentalen Fehlern durchzogen:


    1. Der Reset-Routine läuft nicht nach Spec (nach dem reset CMD können auch andere Werte als 0xFF und 0x01 die rejected werden müssen. Viele Karten antworten mit teilweise gelöschten Flags in der R1 Antwort bevor sie in den idle state gehen, die lib lässt das dann schon als erfolgreiche Antwort durchgehen...)
    2. Jede einzelne Befehlsversand läuft nicht nach Spec (nach jedem gesendeten CMD sind nochmals mind 8 CLK Ticks notwendig, sprich zumindest 1 dummy byte um der karte zeit zu geben sich für den nächsten cmd vorzubereiten)
    3. die MMC-CS line sollte nach jeder Kommunikation de-asserted werden
    4. die ersten 74+ clock ticks zur Initialisierung dürfen nur max 400kHz SPI taktfrequenz (momentan F_OSC/4) haben. während dessen soll eigentlich MMC-CS hi sein (mom schon lo).
    5. es wird kein kartentyp geprüft, sprich es gibt nur eine reset routine. Alle ganz alten und viele älteren Karten brauchen CMD1 zum init und nicht ACMD41.
    6. SDCH funktioniert anderes als SD!!!!!!RufzeichenEins!!! War der längste game-breaker
    Punkt 4-6 ist mir beim Durchsehen des Sourcecodes auch schon aufgefallen. Was ich bei den bereitgestellten Sourcecodes auch etwas schade finde: Beinahe nichts darin ist dokumentiert! Man muss ja nicht jede Zeile dokumentieren, aber zumindest 2-3 Zeilen zu jeder Funktion wären mMn schon ganz gut...

    Zur mp3 lib:
    Sollte unbedingt in der Task-Spec besser formuliert werden werden: Den Decoder erstmalig solange mit Blöcken füttern bis mp3Busy == true dann ist nämlich DREQ auf Gnd gegangen und die ISR kann überhaupt getriggert werden (ISC0 = Rising edge of INT). In jedem interrupt muss dann wieder solange nachgeschaufelt werden bis PD0 lo!

    Quote Originally Posted by qwerty View Post
    den rest macht die ISR (wieder 4. bis 7.)
    Versteh ich dich da richtig, dass du Punkt 4 bis 7 in der ISR ausführst? Ist das nicht etwas zu aufwendig für ne ISR?
    Last edited by bbernhard1; 15-04-2012 at 13:38.

  24. #23
    Master qwerty's Avatar
    Join Date
    Mar 2012
    Posts
    120
    Thanks
    8
    Thanked 19 Times in 14 Posts
    bin für jeden besseren weg dankbar, aber damit der nächste int getriggert werden kann muss DREQ auf lo gehen und das passiert erst wenn der decoder wieder aufgefüllt ist. man müsste mal schauen wie oft die schleife im interrupt durchlaufen wird.

  25. #24
    Baccalaureus bbernhard1's Avatar
    Join Date
    Mar 2010
    Posts
    772
    Thanks
    61
    Thanked 157 Times in 80 Posts
    Quote Originally Posted by qwerty View Post
    bin für jeden besseren weg dankbar, aber damit der nächste int getriggert werden kann muss DREQ auf lo gehen und das passiert erst wenn der decoder wieder aufgefüllt ist. man müsste mal schauen wie oft die schleife im interrupt durchlaufen wird.
    Ich hab das noch nicht mit der Hardware getestet, aber ich hätt mir folgendes überlegt:
    Ich lese die ersten 32Byte von der SD-Karte und schicke diese ans MP3 Modul. Sobald das mp3-Modul wieder Daten entgegennehmen kann (also DREQ auf High ist), wird die ISR aufgerufen in der ein Flag gesetzt wird. Im Hauptprogramm wird nun kontinuierlich überprüft, ob das Flag gesetzt ist. Ist das der Fall, dann wird das Flag wieder gelöscht und die nächsten 32Byte von der SD-Karte gelesen und wieder ans mp3-Modul geschickt. Wie gesagt, ich hab das bisher noch nicht testen können, daher handelt es sich nur um eine theoretische Überlegung. Der Vorteil wäre aber, dass man die ISR damit sehr kurz hält.

  26. #25
    Master qwerty's Avatar
    Join Date
    Mar 2012
    Posts
    120
    Thanks
    8
    Thanked 19 Times in 14 Posts
    wäre eine möglichkeit, es muss aber auf "buffer underrun" geprüft werden, 32kb sind sehr schnell weg... wenn zusätzlich gerade noch irgendwas aufwendigeres gezeichnet wird (noch dazu so zeitaufwendig wies in der spec vorgegeben ist), physik berechnet und mit dem bluetooth modul kommuniziert wird, kanns zum stocken beginnen..

  27. #26
    Baccalaureus bbernhard1's Avatar
    Join Date
    Mar 2010
    Posts
    772
    Thanks
    61
    Thanked 157 Times in 80 Posts
    Quote Originally Posted by qwerty View Post
    wäre eine möglichkeit, es muss aber auf "buffer underrun" geprüft werden, 32kb sind sehr schnell weg... wenn zusätzlich gerade noch irgendwas aufwendigeres gezeichnet wird (noch dazu so zeitaufwendig wies in der spec vorgegeben ist), physik berechnet und mit dem bluetooth modul kommuniziert wird, kanns zum stocken beginnen..
    Das ist natürlich auch ein gutes Argument. Ich kenn das wie gesagt nur so, dass man die ISR möglichst kurz hält (im Idealfall nur ein Flag) setzt, und die Schleife im Hauptprogramm erledigt den Rest. Müsste man aber wohl testen, was bei der konkreten Aufgabenstellung besser funktioniert.

  28. #27
    Baccalaureus Snafu's Avatar
    Join Date
    Sep 2007
    Posts
    688
    Thanks
    5
    Thanked 100 Times in 38 Posts
    Wenn ich mich recht erinnere, dann kommt der MP3 Decoder etliche Millisekunden ohne Daten aus bis der interne Puffer leer ist. Eine Millisekunde ist sehr lange für µC Verhältnisse.
    Microcontroller Tutor

  29. #28
    Master qwerty's Avatar
    Join Date
    Mar 2012
    Posts
    120
    Thanks
    8
    Thanked 19 Times in 14 Posts
    Stimmt, anbei der Verlauf von DREQ während des decodierens:
    Click image for larger version. 

Name:	hantek71_1.gif 
Views:	35 
Size:	19.2 KB 
ID:	20676

    Ist halt die Frage, in welchem Füllgrad der interne Puffer des VS1011, wenn ein DREQ geschieht. Sollte der Puffer dann leer sein und in der ISR erst das Flag gesetzt werden, muss man schauen ob man trotzdem noch unterbrechungsfrei abspielen kann.

  30. #29
    Principal
    Join Date
    Sep 2009
    Location
    Neunkirchen NÖ
    Posts
    43
    Thanks
    28
    Thanked 24 Times in 8 Posts
    Tipp: Interrupts so kurz wie nur irgenwie möglich machen ;-) (zumindest den BLOCKED Teil)
    Last edited by pknoe3lh; 17-04-2012 at 00:09.
    MC Tutor

  31. #30
    Master qwerty's Avatar
    Join Date
    Mar 2012
    Posts
    120
    Thanks
    8
    Thanked 19 Times in 14 Posts
    Wie meinst du blocked? Da steh ich jetzt auf der Leitung...

  32. #31
    Principal
    Join Date
    Sep 2009
    Location
    Neunkirchen NÖ
    Posts
    43
    Thanks
    28
    Thanked 24 Times in 8 Posts
    Also der UART rennt mit 1 MBaud => 16 Befehle pro Bit => 160 Befehle pro Paket => 320 Befehle ohne UART Interrupt das ein Paket nicht übernommen wird.

    Wenn man jetzt viele und lange Interruptroutinen hat und auch viel und lange stellen hat wo Interrupts deaktiviert sind dann kann man schnell über die Magische grenze kommen.
    Und wenn man ein Paket verliert bleibt das BT Module hängen.

    Überprüfen kann man dies wenn man immer vor und nach dem lesen das UART OVERRUN bit ausliest!

    Zu BLOCKED:
    http://www.nongnu.org/avr-libc/user-...l__atomic.html
    MC Tutor

  33. #32
    Master qwerty's Avatar
    Join Date
    Mar 2012
    Posts
    120
    Thanks
    8
    Thanked 19 Times in 14 Posts
    Thx, atomic.h kenn ich, habs im kontext aber nicht verstanden. 320ticks pro interrupt würde aber nur dann gelten, wenn ohne unterbrechung gesendet wird. unter dieser annahme würds aber auch zu sync problemen kommen, wenn aus dem bitstream anfang und ende eines pakets nicht mehr zu erkennen ist.
    Last edited by qwerty; 19-04-2012 at 11:04.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •