| Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
| Autor |
Nachricht |
Speedy
Anmeldungsdatum: 04.01.2003 Beiträge: 54
|
Verfasst am: 17.11.2003, 02:18 Titel: Fehler in fat.c |
|
|
Hallo zusammen,
in der Datei fat.c wird die Variable first_cluster_in_cache verwendet ohne initialisiert zu sein.
Sie wird in der Funktion get_next_cluster verwendet.
Scheinbar berechnet die Funktion die Cluster nicht richtig.
Habe mir in der Debug.c mal ein paar mehr Meldungen eingebaut.
In der Funktion dir_debug wird mit einem Cluster 00000020 gestartet und alle Sektoren dieses Cluster ausgegeben. Dann muss ein neuer Cluster berechnet werden und das Ergebnis sieht wie folgt aus:
Cluster vorher: 00000020
Cluster nach der Berechnung: 00800009
Sehr seltsam!!
Kann mir das jemand erklären??
Speedy
|
|
| Nach oben |
|
 |
Oli
Anmeldungsdatum: 04.01.2003 Beiträge: 109
|
Verfasst am: 20.11.2003, 09:41 Titel: |
|
|
Von welcher Software Version sprichst Du?
[quote]in der Datei fat.c wird die Variable first_cluster_in_cache verwendet ohne initialisiert zu sein. [/quote]
Statische Variablen werden automatisch immer mit 0 initialisiert.
[quote]Scheinbar berechnet die Funktion die Cluster nicht richtig. [/quote]
Wie kommst Du darauf? Scheinbar scheint es ganz gut zu funktionieren, sonst würde das Lesen von Platte nie gehen. Ich behaupte nicht, dass die Funktion korrekt ist, aber ich hatte damit noch keine Probleme. _________________ http://tscherwitschke.de
|
|
| Nach oben |
|
 |
Speedy
Anmeldungsdatum: 04.01.2003 Beiträge: 54
|
Verfasst am: 20.11.2003, 10:12 Titel: |
|
|
[quote="Oli"]Von welcher Software Version sprichst Du?[/quote]
Habe hier Deine an den MiniMega angepasste HD-Version 991m2
[quote]in der Datei fat.c wird die Variable first_cluster_in_cache verwendet ohne initialisiert zu sein.
Statische Variablen werden automatisch immer mit 0 initialisiert.[/quote]
Da ist mir soweit schon klar, aber die Berechnung geht wohl schief.
[quote]Scheinbar berechnet die Funktion die Cluster nicht richtig. [/quote]
[quote="Oli"]Wie kommst Du darauf? Scheinbar scheint es ganz gut zu funktionieren, sonst würde das Lesen von Platte nie gehen. Ich behaupte nicht, dass die Funktion korrekt ist, aber ich hatte damit noch keine Probleme.[/quote]
Das Problem ist nicht so leicht zu beschreiben. Vielleich können wir mal kurz telefonieren.
Kannst mir ja mal Deine Telefonnr. schicken.
|
|
| Nach oben |
|
 |
Speedy
Anmeldungsdatum: 04.01.2003 Beiträge: 54
|
Verfasst am: 20.11.2003, 10:49 Titel: |
|
|
[quote]Scheinbar berechnet die Funktion die Cluster nicht richtig. [/quote]
[quote="Oli"]Wie kommst Du darauf? Scheinbar scheint es ganz gut zu funktionieren, sonst würde das Lesen von Platte nie gehen. Ich behaupte nicht, dass die Funktion korrekt ist, aber ich hatte damit noch keine Probleme.[/quote]
Werde masl versuchen das Problem zu Beschreiben:
Habe mir eine Debug Version gebaut. Diese habe ich mit diversen Statusmeldungen gespickt, die ich über die serielle Ausgeben lasse.
In der Debug version, rufe ich den Punkt 7 auf (dieser ruft die Funktion HDStrukturTest auf)
Innerhalb dieser wird zunächst die Platte über die Funktion ide_init() initialisiert. Dies funktioniert einwandfrei.
Sofort danach wird die Funktion init_fat_debug aufgerufen.
Diese Funktion ruft wiederrum read_lba_debug auf.
Soweit ist auch noch alles OK!
Nun wird in einer while Schleife immer wider die Funktion dir_debug(ActualPath) aufgerufen.
ActulPath ist zunächst 0 und in der Funktion dir_debug der Startcluster.
Innerhalb der Funktion wird bestimmt, wie viele Sektoren ausgelesen werden sollen.
Beim Bootsektor (ActualPath = Cluster = 0) werden zunächst 2045 Sektoren ausgelesen.
Ist Cluster != 0 werden immer 16 Sektoren ausgelesen.
Weiterhin wird der Startsecktor bestimmt.
Beim ersten Aufruf entspricht dies:
Cluster =0; sec_to_read = 2045
Es soll also zunächst der Bootsektor ausgelesen, was auch noch funktioniert.
Sektor für Sektor wird dieser ausgelesen
Irgendwann erreichen wird jedeoch das Ende des Clusters und es muss der nächste Cluster bestimmt werden.
Dazu wird die Funktion get_next_cluster aufgerufen und der derzeitige cluster (0) übergeben.
Diese Funktion berechnet nun auf eine mir nicht verständliche Weise den nächsten Cluster.
Habe mir mal die FAT Spezifikation angesehen.
Hier mal der Auszug:
Eine der wichtigsten Datenstrukturen ist die FAT (File Allocation Table).
Man kann sie sich als verkettete Liste vorstellen. Ein Listeneintrag besteht aus 32 bit,
von denen aber nur 28 Bit zur Adressierung genutzt werden. Im Eintrag wird die Nummer des
nächsten Clusters oder eine Kennung , das die Clsuterkette beendet ist, abgelegt.
Die Verkettung erfolgt für Dateien und Verzeichnisse.
#####################################
#ClusterNr # NächsterCluster 32 Bit #
#####################################
Diese Tabelle wird hinter dem reservierten Bereich gespeichert. Zusätzlich wird aus
Sicherheitsgründen eine oder mehrere Kopien der FAT geführt.
Möchte man für einen Cluster N den Eintrag der FAT ermitteln, muss man zunächst den
entsprechenden Eintrag Sektor von der Festplatte lesen.
Dieser ist für die erste FAT:
ThisFATSecNum = BPB_RsvdSecCnt + ( (N * 4) / 512 )
Der gesuchte Eintrag befindet sich dann ab dem Offset:
ThisFATEndOffset = Rest[ ( (N * 4) / 512) ]
In diesem Eintrag kann man folgende Werte finden:
0x0FFFFFF7 => Fehlerhafter Cluster
0x0FFFFFF8 => End Of File
0x0FFFFFFF => End of Clusterchain
0x0xxxxxxx => nächster Cluster
Ende des Auszug!!!!!!
Der Cluster der hier zurückgeliefert wird ist aber meiner Meinung nach nicht richtig berechnet!
|
|
| Nach oben |
|
 |
Oli
Anmeldungsdatum: 04.01.2003 Beiträge: 109
|
Verfasst am: 21.11.2003, 09:06 Titel: |
|
|
Hi,
Danke für die ausführliche Beschreibung.
Das muss ich mir mal in Ruhe angucken.
Kannst Du in der Zwischenzeit mal diese [url=http://tscherwitschke.de/download/hmpeg_hd-0.991m3b2.zip]Version[/url] testen? Ich hatte schon mal einen Bug in init_fat() gefixt. _________________ http://tscherwitschke.de
|
|
| Nach oben |
|
 |
Speedy
Anmeldungsdatum: 04.01.2003 Beiträge: 54
|
Verfasst am: 21.11.2003, 12:45 Titel: |
|
|
Hallo Oli,
die 991m3b2 läßt sich nicht mit avr gcc3 bauen
Fehler: No rule to ...
mit gcc2 gehts
Weiterhin gibts noch 2 Warnings:
a) Virtual symbol '__interrpt4__' is assigned new value
b) Virtual symvol '__overflow1__' is assigned new value
Was hat sich geändert??
Werde Dir auch mal meine Version zukommen lassen. Dort habe ich ein Menüsystem eingebaut und die gesamte Steuerung integriert. Man brauch jetzt eigentlich nur ein Drehrad zur Steuerung. IR5 und seriell geht natürlich weiterhin.
Auch die ID3 Tag V1 werden auf Wunsch ausgegeben und Displays von 1x16 bis 4x40 werden unterstützt.
Die anzuzeigenden Infos können frei konfiguriert und gescrollt werden.
Wegen der Größe aber nur mit MiniMega kompilierbar.
Jetzt müßte nur noch die Sache mit den Verzeichnissen gelöst werden.
Sprich: Verzeichniswechsel +/- geht leider noch nicht, da es ja den o.g. benannten Bug mit der Clusterberechnung gibt.
Speedy
|
|
| Nach oben |
|
 |
Speedy
Anmeldungsdatum: 04.01.2003 Beiträge: 54
|
Verfasst am: 21.11.2003, 12:59 Titel: |
|
|
Erstes Ergebiss zur 991m3b2
Eine nicht 'Debug' - Version führt bei mir nur zum blinken des Schriftzug "HD V0.991m3". Weiter passiert nix
Eine Debug Version funktioniert, gibt aber beim auslesen des Verzeichnis (DIR 07) nach dem zweiten Lied nur noch HD-Error zurück.
Bootsektor läßt sich auslesen. Achtung: hier fehlt im Code noch ein break am Ende des Switch, da hier nach dem MemDump des Bootsektor auch noch Lese DAT L/H ausgegeben wird.
Speedy
|
|
| Nach oben |
|
 |
Gast
|
Verfasst am: 21.11.2003, 17:17 Titel: |
|
|
Hi,
[quote]
die 991m3b2 läßt sich nicht mit avr gcc3 bauen
Fehler: No rule to ... [/quote]
makefile anpassen. Ziemlich oben.
[quote]Was hat sich geändert?? [/quote]
Siehe minimega-changes.txt
[quote]Jetzt müßte nur noch die Sache mit den Verzeichnissen gelöst werden.[/quote]
Die init_fat muss natürlich auch stimmen, sonst kann es auch krachen. Die alte Version ging nur, wenn das Plattenformat bestimmte Kriterien erfüllte, was aber nach FAT32 Spec nicht garantiert ist.
[quote]Achtung: hier fehlt im Code noch ein break am Ende des Switch[/quote]
Stimmt. Danke.
Ich bin noch nicht dazugekommen, den Fehler anhand Deiner Beschreibung nachzuvollziehen. Ich hab auch nur einen modifizierten Hmpeg mit Yampp Interface, somit ist der Code nicht unverändert bei mir lauffähig.
Oli
|
|
| Nach oben |
|
 |
Speedy
Anmeldungsdatum: 04.01.2003 Beiträge: 54
|
Verfasst am: 21.11.2003, 18:05 Titel: |
|
|
[quote="Oli"]Die init_fat muss natürlich auch stimmen, sonst kann es auch krachen. Die alte Version ging nur, wenn das Plattenformat bestimmte Kriterien erfüllte, was aber nach FAT32 Spec nicht garantiert ist.[/quote]
Soweit ich das nachvollziehen konnte, stimmt die Funktion init_fat.
Habe mich bisher nicht getraut umzubauen, da ich den Drehgeber unbedingt brauche. Auf die RC5 könnte ich verzichten. Seriell muss ebenfalls bleiben.
Lt. Deiner Umbauanleitung würde aber der Drehgeber entfallen => Todeskriterium!
[quote="Oli"]Ich bin noch nicht dazugekommen, den Fehler anhand Deiner Beschreibung nachzuvollziehen. Ich hab auch nur einen modifizierten Hmpeg mit Yampp Interface, somit ist der Code nicht unverändert bei mir lauffähig.[/quote]
Du solltest Dir auf jedenfall Debugmeldungen ausgeben lassen, in denen Du den Cluster ausgibst, der in die Funktion übergeben wird und den Cluster ausgeben, der angeblich der nächste sein soll.
Speedy
|
|
| Nach oben |
|
 |
Oli
Anmeldungsdatum: 04.01.2003 Beiträge: 109
|
Verfasst am: 21.11.2003, 19:47 Titel: |
|
|
So, ich hab jetzt mal meinen Hmpeg angeworfen.
Dabei habe ich meine angepasste Software mit Yampp Interface benutzt, aber der HDStrukturTest() und die restliche FAT Logik dürfte der Version 0.991m3b2 entsprechen.
Die Software liegt [url=http://www.bitbang.de/hmpeg/MiniMegaHmpegYampp.zip]hier[/url], falls Du mal reinschauen willst.
In dir_debug() habe ich ein paar Debug-Ausgaben eingebaut:
Am Anfang gebe ich "cluster" und "sec_to_read" aus und nach Aufruf von get_next_cluster gebe ich "next cluster" und "first_sector" aus.
Die ersten paar Zeilen sehen so aus:
[code:1]
Test der Verzeichnisstruktur
Init Fat:
Lese Root:
cluster: 00000000 sec_to_read: 00006FB4
DIR:\Toktok vs. Soffy O
cluster: 00010002 sec_to_read: 00000010
Belegt im Dirbuffer: 000000E6 Bytes
DIR:\Toktok vs. Soffy O\Toktok vs. Soffy O
cluster: 00010003 sec_to_read: 00000010
Belegt im Dirbuffer: 0000030C Bytes
01 Toktok vs. Soffy O - Day Of Mine (Ludicrous Idiots).mp3
02 Toktok vs. Soffy O - Neighbor.mp3
03 Toktok vs. Soffy O - Jean.mp3
04 Toktok vs. Soffy O - Go.mp3
05 Toktok vs. Soffy O - Siamese Twins.mp3
06 Toktok vs. Soffy O - Missy Queen's Gonna Die.mp3
07 Toktok vs. Soffy O - Changes.mp3
08 Toktok vs. Soffy O - Sixpack.mp3
09 Toktok vs. Soffy O - The Lookalikes.mp3
10 Toktok vs. Soffy O - Talkative.mp3
11 Toktok vs. Soffy O - One Of These Places.mp3
12 Toktok vs. Soffy O - A Pointless Life.mp3
DIR:\Toktok vs. Soffy O\Toktok vs. Soffy O\Test Dir 1
cluster: 00060804 sec_to_read: 00000010
Belegt im Dirbuffer: 00000000 Bytes
cluster: 00010003 sec_to_read: 00000010
DIR:\Toktok vs. Soffy O\Toktok vs. Soffy O\Test Dir 2
cluster: 00060805 sec_to_read: 00000010
Belegt im Dirbuffer: 00000000 Bytes
cluster: 00010003 sec_to_read: 00000010
11 Ugly Kid Joe - Everything About You.mp3
12 Ugly Kid Joe - Madman ('92 Remix).mp3
13 Ugly Kid Joe - Mr. Recordman.mp3
cluster: 00010002 sec_to_read: 00000010
15 Billy Joel - Honesty.mp3
16 Billy Joel - You May Be Right.mp3
17 Billy Joel - Don't Ask Me Why.mp3
18 Billy Joel - Miami 2017 (Seem The Lights Go Out On Broadway).mp3
cluster: 00000000 sec_to_read: 00006FB4
DIR:\Black Sabbath
cluster: 0001249A sec_to_read: 00000010
Belegt im Dirbuffer: 00000012 Bytes
DIR:\Black Sabbath\Paranoid
cluster: 0001249B sec_to_read: 00000010
Belegt im Dirbuffer: 0000017D Bytes
01 Black Sabbath - War Pigs, Luke's Wall.mp3
02 Black Sabbath - Paranoid.mp3
03 Black Sabbath - Planet Caravan.mp3
04 Black Sabbath - Iron Man.mp3
05 Black Sabbath - Electric Funeral.mp3
06 Black Sabbath - Hand of Doom.mp3
07 Black Sabbath - Rat Salad.mp3
08 Black Sabbath - Jack the Stripper, Fairies Wear Boots.mp3
cluster: 0001249A sec_to_read: 00000010
cluster: 00000000 sec_to_read: 00006FB4
[/code:1]
Das komplette Log ist in obigem ZIP enthalten (cluster.txt)
Oli _________________ http://tscherwitschke.de
|
|
| Nach oben |
|
 |
Oli
Anmeldungsdatum: 04.01.2003 Beiträge: 109
|
Verfasst am: 21.11.2003, 20:00 Titel: |
|
|
Init Fat wirft bei mir übrigens folgendes aus:
[code:1]
FAT Start: 0000005F
DIR Start: 0000DFC7
DataStart: 0000DFC7
FAT Länge: 00006FB4
[/code:1] _________________ http://tscherwitschke.de
|
|
| Nach oben |
|
 |
Speedy
Anmeldungsdatum: 04.01.2003 Beiträge: 54
|
Verfasst am: 23.11.2003, 19:14 Titel: |
|
|
Hallo Oli,
habe versucht mal eine Debug Version aus der Datei YamppHmpeg zu bauen.
Nachdem ich ständig mit Warnings bezüglich der veralteten Header-Dateien zugemüllt wurde, habe ich diese durch die neuen gcc3 Header ersetzt.
Nachdem ich dann versuche die Version zu bauen kommt jetzt die nette Meldung
warning: conflicting types for built-in function 'putchar' für die serial.h
und zum krönenden Abschluß noch: undefines reference to 'main'
MAKE: *** [hmpeg_hd.elf] Error 1
Was ist dass für ein Mist??
Sorry - Speedy
|
|
| Nach oben |
|
 |
Gast
|
Verfasst am: 24.11.2003, 23:00 Titel: |
|
|
Das mit putchar kann man umgehen, indem man die Funktion umbenennt, z.b. in Putchar.
Wie man die "undefines reference to 'main'" wegbekommt würde mich selbst interessieren.
Mit GCC 3.0.2 funktioniert's aber noch.
|
|
| Nach oben |
|
 |
|