www.mikrocontroller.net

Forum: Compiler & IDEs Division mit Rest


Autor: Nik Bamert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tut mir langsam echt leid, dass ich immer nerven muss, aber ich denke
ein letztes Mal muss es noch sein.

Ich muss Bei einer Division den Rest festellen, ich möchte also,
falls ich 128 durch 10 teile, eine Variabel mit 12 und eine mit dem
Rest 8 bekommen. Allerdings kann ich die Variante, immer 10 von x
abzuziehen, bis x kleiner als 10 ist nicht verwenden. Und zwar weil das
ganze schneller gehen muss, und auch mit höheren Zahlen.
Eventuell funktioniert es ja auch ohne die Division, sondern mit
Operatoren, aber obwohl ich prinzipiell weiss, was die Operatoren
machen, kann ich mir nicht vorstellen wie ich das anstellen könnte.

Diejenigen die schonmal ein Fat in C programmiert haben, wissen
warscheinlich wo mein Problem liegt. Ich hab den Cluster, und muss den
nächsten finden, dazu muss ich in der Fat tabelle nachschauen.
Doch ich muss ja irgendwoher wissen, in welchem Sektor der gesuchte
Eintrag denn ist und an welcher Position im Sektor.

Falls man eine Division immer dazu zwingen könnte abzurunden, wäre das
vielleicht auch ein Ansatz, aber ich hab keine Ahnung ob das überhaupt
gehen könnte.

Nik

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Einfach:

  a = 128;

  b = a / 10;

  c = a % 10;

Mir ist allerdings nicht klar, wozu Du bei einer FAT-Implementierung
durch 10 teilen musst, aber das wirst Du Dir schon irgendwie erklären
können.

Autor: Nik Bamert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein die 10 war nur ein Beispiel um nicht gleich die grösseren Zahlen
ausgraben zu müssen ;)

Allerdings enthält b nun 13, da es aufgerundet wurde....der Rest stimmt
aber wieder...Kann man gcc irgendwie dazu zwingen abzurunden?

Autor: Nik Bamert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Autsch, sehr peinlich, 0C ist natürlich 12, nicht 13...funktioniert
perfekt so, danke :)

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Btw., die Division ist eine recht kostspielige Angelegenheit (die
teuerste der vier Grundrechenarten).  Prinzipbedingt fällt bei den
Divisionsalgorithmen der Rest der Division gleich immer nebenbei mit
ab.  Von daher gibt es in C einen Funktionsaufruf, der in einem Zug
sowohl die Division als auch den Modulus gleichzeitig zurückgibt.
Die Funktion heißt div() und ist einerseits in jeder C-Bibel
dokumentiert, andererseits natürlich auch in der avr-libc-Doku.

Autor: Nik Bamert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Die Funktion heißt div() und ist einerseits in jeder C-Bibel
>dokumentiert, andererseits natürlich auch in der avr-libc-Doku.

allerdings habe ich hier erst kürzlich gelesen dass die mathematischen
Funktionen der libc ziemlich viel platz verwenden...?

Aber auch wenn die Division nun ein bisschen mehr Rechenzeit in
Anspruch nimmt, das erste mp3 File ab Fat32 läuft, aktuell ist es ein
File mit 128kbit/s. Ich werde mal noch andere Testen ( 192 und 320
kbits).
Interessant wäre sicher auch, mit einem Timerinterrupt die genaue
Anzahl bytes/sek Lesedurchsatz zu errechnen...

Autor: Nik Bamert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das hat nun nicht mehr so viel mit meiner Ursprünglichen Frage zu tun,
aber Ich selbst Dateien mit 380kbits noch korrekt abspielen.

Und falls jemand Fat32 benutzen möchte, sich aber nicht mit der
Microsoft Doku abquälen möchte, dem kann ich diese Seite wirklich
empfehlen: http://www.pjrc.com/tech/8051/ide/fat32.html
Der einzige kleine Nachteil, sie ist auf Englisch.

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> allerdings habe ich hier erst kürzlich gelesen dass die
> mathematischen Funktionen der libc ziemlich viel platz verwenden...?

Ich habe kürzlich gelesen, die Erde sei eine Scheibe...

:-)

Erstens hat das mit ``mathematischer Funktion'' nicht wirklich was
am
Hut, unter solchen versteht man gemeinhin eher die numerischen
Funktionen, also alles, was man in <math.h> beschrieben findet.

Zweitens ist hier ein wichtiger Unterschied: div() macht weiter
nichts, als die ganz normale Divisionsimplementierung aufzurufen, also
dieselbe, die du auch mit den Operatoren / und % aufrufst -- es gibt
dir eben nur beide Resultate gleichzeitig zurück (in Form einer
struct).  Dein Code wird davon also eher kleiner (und schneller
sowieso).

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Nik: Danke für den Tip.

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Ihr,

Ich persönlich fand das Microsoft-paper zum Thema FAT eigentlich sehr
erhellend. Da sind doch sogar Code-Beispiele drin.
Ich habe mit dem Whitepaper als alleinige Referenz meinen FAT16/32-Code
mit Schreiben und Lesen von Dateien und Verzeichnissen implementiert.
&Nik: Die meisten Divisionen und Modulo-Operationen bei
FAT-Implementationen haben folgende Eigenschaften :
1. Sie sind vorab bekannt, wenn man eine bestimmte Festplatte
verwendet.
2. Sie sind 2er-Potenzen und da ist es wesentlich einfacher zu
dividieren und die Modulo-Operation zu implementieren.

Ich habe meinen Code so organisiert, dass man beliebige Festplatten
anschließen kann und die FAT wird gefunden (OK, OK natürlich nur die
erste FAT auf der Platte). Falls man aber zum
Programmerstellungszeitpunkt schon weiß, welche Eckdaten die FAT hat,
dann kann man einen Teil davon bereits vor dem kompilieren
spezifizieren und dann wertvolle Zeit bei der Propgrammausführung und
außerdem noch Speicher sparen.

Ich würde Euch gerne zum jetzigen Zeitpunkt meine FAT-Routinen
vorstellen, sie sind aber noch ein wenig unsortiert und enthalten noch
teilweise kleinere Formatierungsschwächen (Funktion ist einwandfrei).
Ich werde im Laufe des Monats vielleicht noch dazu kommen, die
FAT16/32-Routinen hier mit einer Dokumentation vorzustellen. Kommt
darauf an, wie viel Zeit ich finde.

MfG, Daniel.

Autor: Peter Dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"2. Sie sind 2er-Potenzen"


Und ich hatte mir schon den Kopf zerbrochen, wo zum Teufel denn in der
FAT durch 10 dividiert werden muß.


D.h. die ganze Frage ist falsch.

Es geht garnicht ums Dividieren sondern nur ums rechts schieben und
UNDieren. Und beides ist einsdreifix in wenigen Zyklen erledigt.


Peter

Autor: Nik Bamert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das selbe ist es etwa bei mir, ich habe ein Funktion die erstmal
die erste Partition auf fat32 überprüft, dann die Wichtigsten Daten aus
dem Volume boot record ausliest. (clustergrösse, etc.)
Die wichtigsten paar bytes speichert die Funktion dann in einige
globale Variabeln, damit auch andere Funktionen einfach darauf
zugreifen können. Dann gibts noch eine einfache Funktion die den
Inhalt des Root Directorys ausgibt, eine die eine Datei von einem
bestimmten Cluster beginnt abzuspielen und eine die den nächsten
Cluster aus der Fat ausliest. Insgesamt ist das ganze wie bei dir noch
ziemlichunsortiert(hab die fat unterstützung jetzt in 3 Tagen
geschrieben, alles ist noch ziemlich durcheinander). Das File für ata
und Fat ist etwa 500 Zeilen lang und benötigt warscheinlich etwa 2 bis
3 kb flash. Die Routinen sind zwar nun auf das Auslesen wie es für
einen mp3 player üblich ist optimiert(liest die Datei einfach
fortlaufend). Nun habe ich noch einen Monat Schule bis zu den Ferien,
aber dann kann ich die Sourcen vielleicht auch mal ordnen und Online
stellen. Evtl. werde ich den mp3 Player auch auf auf einen mega8
portieren, der Speicher scheint nämlich locker genug zu sein...und da
der mega8 sogar noch 512byte mehr ram hat als der mega8515 liegen
vielleicht noch einige Sachen mehr drinn, wie ein buffer für einen
ganzen Sektor...was das ganze noch um einiges schneller machen würde.
Falls das dann fertig ist, werde ich es vielleicht als Projektins Wiki
stellen.

Autor: Nik Bamert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>D.h. die ganze Frage ist falsch.

>Es geht garnicht ums Dividieren sondern nur ums rechts schieben und
>UNDieren. Und beides ist einsdreifix in wenigen Zyklen erledigt.

Im prinzip ist sie nicht falsch, denn so funktionierts auch,
vom "rechts schieben und UNDieren" hab ich leider noch nicht
allzuviel Ahnung...

Autor: Volkmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Nik,

falsch ist Deine Lösung nicht, aber nicht optimal. Du schriebst ganz am
Anfang:

> Und zwar weil das ganze schneller gehen muss

Und das geht mit den Schiebeoperationen definitiv schneller. Beispiel
mit Teiler durch 128:

rest = wert & 127;
ergebnis = wert >> 7;

Volkmar

Autor: Peter Dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Nik

"vom "rechts schieben und UNDieren" hab ich leider noch nicht
allzuviel Ahnung..."


Nimm eine Dezimalzahl, teile sie durch 10 bzw. schiebe sie eine Stelle
nach recht (letztes Digit fällt weg) und nun vergleiche beide
Ergebnisse miteinander.

Was könnte nun passieren, wenn man eine Binärzahl durch 2 teilt bzw.
eine Stelle nach recht schiebt ?


In meinen Augen gehören Kenntnisse über die interne Darstellung von
Ganzzahlen im MC/PC und Grundrechenarten mit Binärzahlen zum absoluten
Basiswissen eines jeden Programmierers.


Sonst kommt noch sowas raus wie neulich, als jemand allen Ernstes mit
sage und schreibe 10240 IF-Abfragen einen 10Bit-Binärwert nach dezimal
wandeln wollte !!!

http://www.mikrocontroller.net/forum/read-1-196647.html#new


Auch sollte man wissen, wann und warum z.B. 65535 + 10 = 9 rauskommt.


Peter

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

da muss ich Dir zustimmen - mir kämen 10240 (!) if-Anweisungen schon
recht viel Aufwand vor ;-).

Aber natürlich hast Du sonst auch ernsthaft recht.

MfG, Daniel

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> In meinen Augen gehören Kenntnisse über die interne Darstellung von
> Ganzzahlen im MC/PC und Grundrechenarten mit Binärzahlen zum
absoluten
> Basiswissen eines jeden Programmierers.

Nik hat doch nirgends behauptet, dass er ein Programmierer ist. Das du
das alles von Geburt an kannst, hat sich ja hier mitlerweile
rumgesprochen.

Autor: ---- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Nik hat doch nirgends behauptet, dass er ein Programmierer ist. Das
> du das alles von Geburt an kannst, hat sich ja hier mitlerweile
> rumgesprochen.
Polemischer Unsinn - zumal Peter immer versucht (und es ihm gelingt)
neutral zu bleiben und keinem auf den Schlips zu treten.

Ich bin sicher Nik würde ihm auch recht geben.

----, (QuadDash).

Autor: Nik Bamert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>In meinen Augen gehören Kenntnisse über die interne
>Darstellung von Ganzzahlen im MC/PC und
>Grundrechenarten mit Binärzahlen zum absoluten Basiswissen
>eines jeden Programmierers.

Grundrechenarten mit Binär Zahlen sind auch nicht mein Problem, Sachen
die ich nicht verstehe sind Masken etc mit &, | usw. Auch wenn man das
in Visual Basic oder Bascom verwenden kann, ich habs bis jetzt
schlichtwegs nicht gebraucht, da ich noch nie Programme in die Richtung
programmiert habe, auf dem Pc waren es hauptsächlich Netzwerk Programme
wie zum Beispiel ein http server. Nun in Visualbasic gibts auch einen
Befehl um z.b. den Rest aus zurechnen, und zwar schlicht und eifach
"mod" wenn ich mich recht errinere. Dazu braucht man dann nicht
gerade
Kentnisse wie man die bits hin und her schieben kann...
Nun habe ich eigentlich als erstes grösseres C programm, diesen
Mp3 Player programmiert, und ja, als Programmierer bezeichne ich mich
dennoch, das einzige was ich nicht selbst gemacht habe sind die
Funktionen für den Uart und eben die Sachen, die ich hier nachfragen
musste.

>65535 + 10 = 9

Warum dies nun ergibt ist mir auch klar, wäre die Variabel 32 bit lang

wäre das Ergebniss wohl viel eher 65545 ;-).
Da die Variabel aber anscheinend 16 bit lang unsigned ist, gibt das
ganze eben den übertrag nicht an das nächste bit weiter, sondern wieder
an das erste, welches folglich "überläuft" und wieder bei Null
anfängt. Ich denke das das so einigermassen korrekt war, da ich
die Innereien von addierwerken bis jetzt noch längst nicht in der
Schule hatte(bin 15), sondern mir das bis einigermassen selbst
beigebracht habe. Das soll aber nicht heissen das ich nun
irgendjemanden Böse wäre,

>Ich bin sicher Nik würde ihm auch recht geben.
trifft nämlich zu.

mfg Nik

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In C gibt es auch einen "mod"-Befehl, nur wird der C-typisch knapper
geschrieben - das ist das von mir im zweiten Beitrag in diesem Thread
erwähnte %.

@Nik: Weiter so.

Autor: Nik Bamert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>@Nik: Weiter so.
danke danke :)

Nun, ich hab grad was ziemlich krasses entdeckt; entweder sind meine
Fat Routinen derart schnell, oder ich spinne...naja, jedenfalls hab
ich
hier ein lied, das normal 5 minuten 18 sekunden, das mit einer Bitrate
von 128 kbit. Nun hab ich spasseshalber mal den Befehl weggelassen,
der
auf Dreq wartet. Folglich sendet das die Daten so schnell wie möglich;
nach 10 sekunden war nichts mehr zu höhren und der song war fertig.
Falls das überhaupt möglich ist, hätte das ganze ja dann mit
490 kbyte/sek gelesen (file Grösse ist 4977kbyte).
Nun kann ich mir das aber kaum vorstellen, ich verwende nämlich nur
einen 7.xxx Quarz verwende.

Gibts vielleicht eine einfache möglichkeit die Geschwindigkeit
zu messen? (In Sofware meine ich jetzt, sonst geht ein 10mb file und ne
Stoppuhr ja auch ;) )

mfg Nik

Autor: Nik Bamert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mist, 7.xxx sollte 7.3728 Mhz heissen

Autor: Nik Bamert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich hab nun ein ziemlich genaues Ergebniss; 102 kbyte/sek,
die Dateien werden dabei aber auch noch über spi versandt, Quarz
ist wie gesagt nicht ein mal 8 mhz schnell, ausserdem habe ich kein
Buffer für die Fat Tabelle oder derartiges, sondern für alles immer nur
einer mit 32 byte. Mit einem 16 mhz Quarz und ohne übers spi senden
könnten da doch gut 200 kbyte/sek drin sein denke ich...

Autor: Volkmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Nik,

da Du über die Lesegeschwindigkeit schreibst, wüßte ich gerne, was für
ein Speichermedium Du verwendest. Leider kam es bisher nicht rüber oder
ich habe es überlesen.

Volkmar

Autor: Nik Bamert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oppala, stimmt ja :) im Moment hab ich eine Festplatte mit 40 gb dran.

Autor: Erik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Nik!

Ich finde dein Projekt sehr interessant! Ich hoffe du kannst es bald
veröffentlichen, ich werde es gerne lesen. Momentan hab ich eine CF an
einem uC, und ich bringe 300kB/s hin. Da ich bald mit HD's
experimentieren will, verfolge ich diesen Thread schon länger.
Danke für den FAT-Link!

Autor: Nik Bamert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich finde dein Projekt sehr interessant!
>Ich hoffe du kannst es bald veröffentlichen, ich werde es gerne lesen

Das ist eigentlich auch mein Ziel, ich werde mich dann dahinter machen
wenn die Prüfungen erst mal vorbei sind. Zudem muss ich den Code noch
ziemlich aufräumen(Funktionen die ich zum debuggen
benutzt habe rauslöschen etc.)

Dann muss ich mir noch einiges überlegen wie ich das ganze mit den Fat
Funktionen eingermasses klug beschreiben kann-denn ich hab ja keinen
Buffer verwendet, der einen ganzen Sektor speichert, das ginge auch gar
nicht, da der mega8515 ja nur 512 byte ram hat.
So kam es dann das ich drei verschiedene kleinere buffer habe...

>Momentan hab ich eine CF an
>einem uC, und ich bringe 300kB/s hin.

Woah das ist ganz schön heftig,
was für einen Controller  Compiler  Quarz verwendest du denn?

>Da ich bald mit HD's experimentieren will,
>verfolge ich diesen Thread schon länger.

Für Hardware/Software für hdd's kann ich bis jetzt mal den Source von
Yampp3 empfehlen (http://www.myplace.nu/mp3/yampp3.htm)

Ich wollte anfänglich den yampp3 nachbauen, doch habe ich dann
bemerkt,
das man wegen des memory interface timings leider nicht so einfach
einen atmega8515 anstelle des verwendeten at90s8515 beenutzen kann,
obwohl die bei atmel das eigentlich schreiben...)
Desshalb ist meine Hardware grösstenteils gleich aufgebaut, ausser
das ich eben kein Ram benötige.

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich wollte anfänglich den yampp3 nachbauen, doch habe ich dann
> bemerkt, das man wegen des memory interface timings leider nicht so
> einfach einen atmega8515 anstelle des verwendeten at90s8515
> beenutzen kann,

Was ist denn daran so grundlegend anders?

Ganz davon abgesehen, AT90S8515 bekommst du doch fast
hinterhergeworfen...

Autor: Erik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Nik!

Thanks für den yamp3-Link. Ich hab das in Assembler geproggt, die
Routinen zum Schreiben/Lesen sind optimiert und laufen auf nem mega32
@16MHz. Die Geschwindigkeit ist sehr von der verwendeten Karten
abhängig, neue CF's sind Ca. 4x schneller als ältere, neuere Karten
sind allerdings oft nicht kompatibel. Ich hab mit ner alten 16MB von
Sandisk angefangen, alle neuen Karten von Sandisk funktionieren mit den
gleichen Routinen nicht mehr zuverlässig! Ser empfehlen kann ich die
Elite Pro Karten von Kingston, die sind einfach spitze!
Mich würde ein tragbarer mp3-Player mit einer 4GB Karte und Fat32
reizen, viel Speicher, wenig Strom und vorallem keine mechanische
Harddisk! Mal sehen ob deine Fat-Routinen mich inspirieren, hab im
Moment leider nicht so viel Zeit und werde dann gleichzeitig mein 1.
Projekt in C starten.

Gruss.

Autor: Nik Bamert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jörg

>Was ist denn daran so grundlegend anders?
Was es genau ist, kann ich nicht sagen, ich habs selbst mit Datenblatt
nicht herausfinden können. Das Timing ist irgendwie schneller und
somit
funktionierte die Ansteurung vom ram/hdd nicht mehr mit der yampp3
software. Ich hab nach etwa 2 wochen rumprogrammieren an dem prog.
von yampp entschlossen aufzugeben, dafür aber mein eigenes Programm zu
schreiben, dabei lerne ich schliesslich auch noch was :)

>Ganz davon abgesehen, AT90S8515 bekommst du doch fast
>hinterhergeworfen...
Das dachte ich zuerst auch, doch dann musste ich leider festellen,
das ich in der Schweiz wohl nur noch an die atmegas rankomme,
die at90s8515 fand ich nur noch beim grossen C und bei dem mit
angegebener Lieferzeit von mehr als 2 wochen....

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tja, ohne Mailadresse keine Hilfe...  (Ich wollte dir 'ne PM
schreiben.)

Vielleicht hast du einfach nur ein zu langsames Latch genommen?  Hast
du die Taktfrequenz gegenüber yampp hochgesetzt (der mega kann ja
mehr)?  Das Latch ist kritischer als der RAM selbst.

Autor: Nik Bamert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich gib die email Adresse eigentlich an, hab das hier früher auch
gemacht, nun wegen den vielen die sich Gedanken machen wegen
irgendwelchen Spam attacken dachte ich mal ich lass die adresse weg,
bis
jemand fragt, also häng ich sie nun mal an :D

Das es das Latch war denke ich aber weniger, ich hab mehrere
ausprobiert,
einmal ein HC, aber auch einmal ein hct. Dann habe ich auch alle
beim mega8515  neuen sram waitstate bits gesetzt, damit alles
möglichst
langsam abläuft, einmal mit at90s8515  compatible fuse und einmal
ohne,
beide Male ging nichts :( Aber im Moment verwende ich immer noch
dasselbe Latch für die Ansteuerung der hdd um einige Anschlüsse zu
sparen,
und es läuft :P

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, die email-Adressen sind ganz gut geschützt, das at-Sign ist ja
eine kleine Grafik. ;-) Merkst du mit einem grafikfähigen Browser
nicht direkt.

> Das es das Latch war denke ich aber weniger, ich hab mehrere
> ausprobiert, einmal ein HC, aber auch einmal ein hct.

Hmm, die Manpage meint:

``When operating at conditions above these frequencies, the typical
old style 74HC series latch becomes inadequate. The external memory
interface is designed in compliance to the 74AHC series latch.''

Nach meinen Erfahrungen kommt es auf die RAM-Geschwindigkeit nicht so
sehr an, auf die des Latches schon.

(Meine Erfahrungen beziehen sich auf einen ATmega128, aber der sollte
nicht grundlegend anders als ein ATmega8515 sein, auch was das Timing
betrifft.)

Autor: Nik Bamert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bins nochmals ;-)

Es wär wohl ziemlich doof wenn ich nun für das einen neuen Thread
mache...desshalb halt einfach nochmals hier.

Also bis jetzt kann der Player:
+Fat32
+Lange Dateinamen(jedenfalls die ersten 12 Zeichen mit
gross/kleinschreibung)
+Subdirectories
+Files mit 320kbits gehen ohne probleme
+Steuerung mit Rotary Encoders..

-Die Drehencoder bereiten noch einige Probleme, die Drehrichtung wird
nicht immer ganz erkannt.

Im Prinzip sollte das später so funktionieren, dass es einen
Drehencoder mit und einen ohne Taste gibt.

Der mit Taste ist für die Songauswahl/Navigation gedacht(die Taste fürs
selektieren/play)
Und der ohne Taste, um die Lautstärke einzustellen

Also alles in allem funzt eigentlich alles perfekt, bis halt auf
diese Drehencoder...soll heissen, fall noch Interesse besteht, könnte
ich nächste Woche oder so ja mal etwas dazu ins Wiki stellen.(?)

Mfg Nik

Autor: Peter Dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Nik

"Die Drehencoder bereiten noch einige Probleme, die Drehrichtung wird
nicht immer ganz erkannt."


Hast Du mal in die Codesammlung gesehen ?

Nen Timerinterrupt wirst Du ja bestimmt schon benutzen, einfach da mit
reinhauen.


Peter

Autor: Nik Bamert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja deinen Code hab ich schon entdeckt ;-)
Ich werds dann vielleicht auch mal mit deinem Versuchen.

Bei mir geht das bis jetzt etwa so:

KanalA an Int0 KanalB an einen beliebigen anderen Pin
SIGNAL(SIG_INTERRUPT1)                        // rottary switch
interrupt
{

u08 a,b;
         a = bit_is_set(MCUCR,ISC10) ? 0 : 1;
   b = bit_is_set(PIND,PD4) ? 1 : 0;

    cbi(GIMSK, INT1);
   //delay(500);

    if (a==b)            // rottary second input
    {
      PRINT("UP!");LoadFileInfo('n');
  }else{
      PRINT("DOWN!");LoadFileInfo('p');
    }
  
 
  if(a==1)
    {
      sbi(MCUCR, ISC10);
      sbi(MCUCR, ISC11);
    }
  
  if(a==0)
    {
      cbi(MCUCR, ISC10);
      sbi(MCUCR, ISC11);
    }

  sbi(GIMSK, INT1);
}


Der Code ist  allerdings auf auf einen ec-11b von alps ausgerichtet,
denn die machen ja nur 1/2 des signals(soll heissen bei jeder rastung
wechseln kanal a und b von low auf high oder umgekehrt, allerdings
nicht wieder in den Ursprungszutand...)

Nun seit ich an den Eingängen noch C mit 100nF rangeklemmt habe geht
das ganze schon sehr zuverlässig, etwa 5/100 vorgängen werden aber
immer noch falsch interpretiert. Wenn ich das nicht selbst noch besser

hinbekomme, seh ich mir gern mal deinen Code an, ich brauch bis jetzt
nämlich nicht mal einen einzigen Timerinterrupt ;-)

mfg Nik

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.