Hallo Community, ich arbeite gerade an einem Prgramm mit dem ich Melodien über einen uC (ATmega8a)abspielen möchte. Das Programm funktioniert einwandfrei und die Melodien Werden in zwei 8-bit Array mit einmal dem Ton (Zahlenwerte 0 - 38) und im anderen der Tondauer (Zahlenwerte 0 - 15). Auf diese Art und weise verschwende ich jedoch 6 bit von insgesagt 16 bit, da ich ja nur 6 + 4 bit brauche. Ich könnte also 37,5% Speicher einsparen und bei bisher 650 verwendeten Byte ist das nicht zu vernachlässigen. Gibt es eine einfache oder gute Möglichkeit den kompletten Speicher auszunutzen?
Tobias K. schrieb: > Gibt es eine einfache oder gute Möglichkeit den kompletten Speicher > auszunutzen? Bei der Tondauer ist es ja einfach. Da du dafür genau 4 Bit brauchst, kannst du einfach zwei Stück in ein Byte schreiben, dann hast du schon 4 von deinen 6 Bit gespart. Ob es sich jetzt lohnt, die restlichen 2 Bit auch noch einzusparen, musst du dir überlegen. Vielleicht kannst du dir ja alternativ noch ein nettes Zusatzfeature einfallen lassen, für das du die Bits nutzen kannst (z.B. vibrato).
Wenn der Speicher kanpp ist, nimm einfach den ATmega328.
Rolf M. schrieb: > Bei der Tondauer ist es ja einfach. Da du dafür genau 4 Bit brauchst, > kannst du einfach zwei Stück in ein Byte schreiben, dann hast du schon 4 > von deinen 6 Bit gespart. Danke für den Tipp, die Idee hatte ich auch schon und werde ich vermutlic hauch umsetzten. Die restlichen 2 Bit wären da nicht so einfach unter zu bringen. Gibt es C ne möglichkeit einen 6 bit Datentyp zu definieren, der mir einfach nacheinander en Speicher auffüllt, weil mit bitschieberein wird das nicht allzu toll
Wenn man Ton und Dauer zusammenfasst, kommt man auf 624 unterschiedliche Noten. Im wirklichen Leben verwendet eine Melodie aber nur einen kleinen Teil davon. Du könntest max. 255 unterschiedliche Noten erlauben und die Melodie in einem normalen Byte Array speichern. Zum Abspielen gehst du einen Umweg über eine Lookup Table, die dir Tonhöhe und Tondauer für eine bestimmte Note liefert. Diese Tabelle muss nur so viele Einträge haben, wie die Melodie unterschiedliche Noten hat. "Alle meine Entchen" für Xylophon kommt mit weniger als 16 aus ;) Da könnte man auch noch 2 Noten pro Melodie-Byte speichern. Der GCC kennt __attribute__((packed)) für ein typedef struct. Damit kann man im Prinzip beliebig kurze Datentypen erzeugen. Allerdings wird der Code für die Zugriffe auf gepackte Daten u.U. ziemlich groß und langsam.
Tobias K. schrieb: > Gibt es C ne möglichkeit einen 6 bit Datentyp zu definieren, der mir > einfach nacheinander en Speicher auffüllt, weil mit bitschieberein wird > das nicht allzu toll Nein, so etwas gibt es nicht, und um Bitschieberei kämst Du so oder so nicht herum. Der Compiler würde sie, wenn er Datentypen unterstützen würde, die kleiner sind als ein Byte, zwar vor Dir verbergen, aber geshiftet werden muss so oder so. Auch Bitfelder helfen Dir nicht bei Deinem Problem. Entweder Speicher sparen und wüste Shift-Orgien, oder Speicher "verschwenden" mit deutlich weniger Programmieraufwand. Du könntest natürlich auch überlegen, ob Deine Datenstruktur so, wie sie ist, sinnvoll ist. Musst Du für jeden angeschlagenen Ton jedesmal einzeln dessen Lautstärke festlegen, oder würde es nicht vielmehr genügen, nur bei Lautstärkenänderungen die Lautstärke festzulegen? Dann könntest Du mit einem Byte pro Operation - Ton anschlagen bzw. Lautstärke ändern - auskommen. Was hier übrigens fehlt, ist die Zeitinformation; wie lange soll ein Ton erklingen? Auch das könntest Du in diesem Format unterbringen, wenn Du die oberen zwei Bits eines jeden Bytes für die Unterscheidung Ton/Lautstärke/Länge vorsiehst, hast Du jeweils sechs Bits (0..63) für den jeweiligen Wert zur Verfügung. Und Du brauchst immer noch nur ein Byte pro Kommando. Eine Melodie könnte dann so aussehen: D4 L5 T1 T5 T7 L3 D2 T2 L5 D4 T3 T8 T16 L1 T1 L8 D1 T8 T9 (T für Ton, L für Lautstärke und D für Dauer)
Gast
#5516043
Es ist kein Problem die Daten zu "packen", aber... Hast Du so viel Rechenleistung über? Da fallen bei jedem Datum etliche Zwischenbefehle an. 1. Eigene Adressberechnungen. 2. Schiebebefehle. 3. Maskierungssachen. Bei Tönen geht es oft relativ zügig zu.
Tobias K. schrieb: > die Melodien Werden in zwei 8-bit Array mit einmal dem Ton (Zahlenwerte > 0 - 38) und im anderen der Tondauer (Zahlenwerte 0 - 15). 39 x 39 x 39 = 59319. Du kannst also 3 Ton-Werte in 16 Bits packen. Ist halt etwas langsamer, da ranzukommen.
Gast
#5516100
Rufus Τ. F. schrieb: > Auch Bitfelder helfen Dir nicht bei Deinem Problem. Man kann Bitfelder benutzen, um das Problem zu lösen. Ziel ist es, diesen "10 Bit Datentypen" in ein Array ohne padding zu speichern. Es gibt genau 4 Möglichkeiten, wie die 10 Bit in 2 aufeinander folgenden Bytes angeordnet sein können. Es werden also 4 Bitfelder benötigt.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
58 | |
59 | |
60 | |
61 | |
62 | |
63 | |
64 | |
65 | |
66 | |
67 | |
68 | |
69 | |
70 | |
71 | |
72 | |
73 | |
74 | |
75 | |
76 | |
77 | |
78 | |
79 | |
80 | |
81 | |
82 | |
Danke für die ganzen tollen Antworten. Werde jetzt vermutlich einfach die Dauern (4bit) immer zu zweit in ein Byte packen, da sich das nicht allzu kompliziert realisieren lässt.
Rufus Τ. F. schrieb: > Was hier übrigens fehlt, ist die Zeitinformation; wie lange soll ein Ton > erklingen? Ich hätte vermutet, dass der Paramter "Tondauer" das angibt. ;-) Ich glaub, du hast da was verwechselt.
Gast
#5516685
Tobias K. schrieb: > Auf diese Art und weise verschwende ich jedoch 6 bit von insgesagt 16 > bit Dann speichere deine Melodie eben nicht als Array, sondern als Bitstream. Einfach nahtlos die jeweils 10 Bit aneinanderkleben und fertig. Das Auseinandernehmen geht genauso einfach - jedenfalls bei einem 32 Bitter. Kann dein µC wenigstens 16 Bit Operationen ohne Umstände? Also etwa in dem Stil:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
W.S.
W.S. schrieb: > Kann dein µC wenigstens 16 Bit Operationen ohne Umstände? Das wird der Tobias K. schrieb: > ATmega8a eher nicht können. Der kann nicht mal 8 Bit um mehr als 1 Bit am Stück schieben. Dein Code wird darauf also besonders ineffizient sein. Spielt aber vielleicht an der Stelle gar keine so große Rolle.
Rolf M. schrieb: > Der kann nicht mal 8 Bit um mehr als 1 Bit am Stück schieben. Er kann auch 4 Bit und 8 Bit am Stück und GCC weiss das. ;-) Solange die Shiftcount konstant ist, und der Datentyp nicht zu breit, gibt GCC sich respektable Mühe, effizienten Code auszuwerfen.
Gast
#5517167
A. K. schrieb: > Solange die Shiftcount konstant ist, und der Datentyp nicht zu breit .. was beides hier nicht zutrifft. Fazit: Der Chip ist zu mickrig für diesen Einsatz. W.S.
W.S. schrieb: >> Solange die Shiftcount konstant ist, und der Datentyp nicht zu breit > > .. was beides hier nicht zutrifft. > Fazit: Der Chip ist zu mickrig für diesen Einsatz. Es kommen nur 2 Feldlängen vor. Folglich kann man einen Bitstream implementieren, ohne dynamische Shifts verwenden zu müssen. GCCs Optimierung der Shifts für AVR betrifft 16-Bit Daten. Das ist hierfür breit genug. Ein besserer µC ist dafür freilich von Vorteil. Wenn der Dividieren kann, dann geht auch die erwähnte und sparsamste Radix-39 Codierung recht flott.
Gast
#5517378
W.S. schrieb: > A. K. schrieb: >> Solange die Shiftcount konstant ist, und der Datentyp nicht zu breit > > .. was beides hier nicht zutrifft. > > Fazit: Der Chip ist zu mickrig für diesen Einsatz. Oder das Programm ist nicht ausreichend für den Chip optimiert. Ob man jetzt gleich auf eine komplett andere Architektur umsteigen muss, nur weil die Trivial-Implementation von ein paar Bit-Schieberein sonst nicht effizient wäre?
W.S. schrieb: > Fazit: Der Chip ist zu mickrig für diesen Einsatz. Klarer Full für einen 10-Bitter. Der kann das.
Tobias K. schrieb: > Ich könnte also 37,5% Speicher einsparen und bei > bisher 650 verwendeten Byte ist das nicht zu vernachlässigen. Alternativ könntest du auch die Melodie ins Flash legen (mit __flash oder PROGMEM). Damit ist deine Melodie zwar nicht kleiner, aber du sparst RAM. Im Gegensatz zum Flash geizen die Chips mit RAM. :-)
Gast
#5517893
Ich musste auch mal 4 x 10 bit AD-Werte etwas umpacken. (In 5 Bytes a 8 Bit.) Über C habe ich mir gar nicht erst den Kopf zerbrochen, sondern gleich den Assembler angeworfen. Herausgekommen ist eine lustige Schiebeorgie, die bemerkenswerterweise beim Aufruf sowohl die Daten packen als auch entpacken kann. Wohlgemerkt mit der selben Routine. Wie nicht anders zu erwarten reichen genau 42 Zeilen Assembler dafür. Das soll in C erstmal einer nachmachen...
Sempfdazugeber schrieb: > Wohlgemerkt mit der selben Routine. Du hättest die Routine ja netterweise dazulegen können. So bist du nur ein Schwafler. Tacuisses, philosophus mansisses.
Gast
#5518212
> Du hättest die Routine ja netterweise dazulegen können. Die war fuer einen Kleinen PIC und haette dem TO also so nuex genuetzt. Der TO soll sich gefaelligst selber mit Assembler beschaeftigen. Fuer Copy & Pasta spende ich hier nicht!
>> Tacuisses, philosophus mansisses. > Fuer Copy & Pasta spende ich hier nicht! Danke für den Beweis. :-D
Gast
#5518396
> Danke für den Beweis.
Nuex zu danken. :-=
Gast
#5518408
P.S.: > ein Schwafler Schwafler sind die, die ihre Postings mit: > Hallo Community, beginnen und selber nuex zu 100 % zustande bringen. Wenn nur C im Kopf ist, kann auch nur C rauskommen. Eine Datenwortbreite von 10 bit legt auf einem 8 bit Controller ohnehin eine schnelle Assemblerroutine nahe. Und wenn da bei ihm da nuex ist, muss er es halt lernen. Nur der harte Weg ist der richtige. Lächeln und Winken!
Moby, bist du es?
Sempfdazugeber schrieb: > Wie nicht anders zu erwarten reichen genau 42 Zeilen Assembler dafür. > > Das soll in C erstmal einer nachmachen... Was? Dass man so viele Zeilen dafür braucht?
Gast
#5518508
Sempfdazugeber schrieb: > Ich musste auch mal 4 x 10 bit AD-Werte etwas umpacken. > (In 5 Bytes a 8 Bit.) Wie waren denn Ein- und Ausgabendaten kodiert? Z.B. die 4x 10bit als 4x 16 Bit Ints und die 5 Byte? 4x8 Bit und dann ein Byte mit den restlichen 4x2 Bit? Oder als Bit-Stream? > Herausgekommen ist eine lustige Schiebeorgie, die bemerkenswerterweise > beim Aufruf sowohl die Daten packen als auch entpacken kann. > Wohlgemerkt mit der selben Routine. Ohne Fallunterscheidung? Dann können die Eingabedaten wohl nicht als 4x16Bit kodiert gewesen sein... > Wie nicht anders zu erwarten reichen genau 42 Zeilen Assembler dafür. In C werden es wohl deutlich unter 42 Zeilen sein. Wäre jetzt nur interessant, wie viel Zeilen Assemblercode der Compiler daraus macht.
Gast
#5518512
> Was? Dass man so viele Zeilen dafür braucht? Ja, das Loop Unrolling ist schuld daran! Aber, es soll ja schnell gehn. Aber es sind gut investierte 42 Worte im Flash. > Rolf M. Bist du der von der beirischen Trinkerrunde?
Gast
#5518522
> die 4x 10bit als 4x 16 Bit Ints [x] > und die 5 Byte? 4x8 Bit und dann ein Byte mit den restlichen > 4x2 Bit? Oder als Bit-Stream? Wie speichert man wohl 5 Byte... (Tipp: hintereinander...) Es ging bei mir auch um Wandlerdaten von einem AD. Und kein schnoedes Tongepiepse. > In C werden es wohl deutlich unter 42 Zeilen sein. Wäre jetzt nur > interessant, wie viel Zeilen Assemblercode der Compiler daraus macht. Nicht schwafeln sondern machen!
Gast
#5518527
>> sowohl die Daten packen als auch entpacken kann. >> Wohlgemerkt mit der selben Routine. > Ohne Fallunterscheidung? Dann können die Eingabedaten wohl nicht als > 4x16Bit kodiert gewesen sein... Unsigned ints waren es. Das Resultat waren 5 unsigned chars. Beim Auspacken natuerlich andersrum. Auf eine C-Routine die das ebenfalls ohne Fallunterscheidung schafft, waere ich ja mal gespannt :-). Und ja: Es gibt keine Fallunterscheidung zwischen den Operationen Packen und Entpacken in der Assemblerroutine. Was in den 4 uints steht, landet in den 5 uchars und vice versa. In einem Arbeitsgang. > Moby, bist du es? [ ]
Gast
#5518541
A. K. schrieb: > GCCs Optimierung der Shifts für AVR betrifft 16-Bit Daten. Das ist > hierfür breit genug. > > Ein besserer µC ist dafür freilich von Vorteil. Wenn der Dividieren > kann, dann geht auch die erwähnte und sparsamste Radix-39 Codierung > recht flott. OK, dann geht die Schieberei ja doch ausreichend gut. Aber vom Dividieren würde ich doch eher absehen. W.S.
Gast
#5518564
Sempfdazugeber schrieb: > Ich musste auch mal 4 x 10 bit AD-Werte etwas umpacken. > (In 5 Bytes a 8 Bit.) jaja. So, nachdem hier viel Senf geflossen ist, kommt zum Abschluß noch ne Portion Mayo:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
Das war von mir, ist rund 10 Jahre alt und stammt aus meiner eigenen Firmware für den FA-NWT (Funkamateur-Wobbler). Und es sind dort 9 Bit pro Meßwert und 7 zu benutzende Bits in den zu sendenden Bytes. Quasi Radio Eriwan. Klar: In Hochsprache notiert sich sowas viel einfacher, aber was da als MC herauskommt, ist gerade in solchen Fällen gruseliger. So ist das eben, wenn man was auf nem 8 Bitter durchziehen muß. W.S.
Sempfdazugeber schrieb: > Nicht schwafeln sondern machen! Sagt der Schwafler.
Sempfdazugeber schrieb: >> Was? Dass man so viele Zeilen dafür braucht? > > Ja, das Loop Unrolling ist schuld daran! Ja, das ist eben der Nachteil, wenn man das in Assembler macht: Da muss man sich um sowas von Hand kümmern. >> Rolf M. > > Bist du der von der beirischen Trinkerrunde? ?
Warum ist Geschwindigkeit hier überhaupt ein Thema? Selbst die kürzesten Töne werden mindestens 10 ms lang sein, sonst würde man sie gar nicht mehr als solche wahrnehmen. Nachdem der ATmega die Periodendauer eines Tons in ein entsprechendes Timer-Register geschrieben hat, hat er somit alle Zeit der Welt, um die Daten für den nächsten Ton vorzubereiten. Sempfdazugeber schrieb: > Ich musste auch mal 4 x 10 bit AD-Werte etwas umpacken. > (In 5 Bytes a 8 Bit.) > > Über C habe ich mir gar nicht erst den Kopf zerbrochen, > sondern gleich den Assembler angeworfen. > > Herausgekommen ist eine lustige Schiebeorgie, die bemerkenswerterweise > beim Aufruf sowohl die Daten packen als auch entpacken kann. > Wohlgemerkt mit der selben Routine. > Wie nicht anders zu erwarten reichen genau 42 Zeilen Assembler dafür. Hast du den Code mit NOPs aufgefüllt, um auf die 42 zu kommen? ;-) Da der TE keine 10-Bit-Zahlen braucht, sondern jeweils eine 4Bit- und eine 6-Bit-Zahl, ist noch jede Menge zusätzlicher Bit-Operationen nötig, um am Ende jeden der insgesamt 8 Zahlenwerte in einem eigenen Register stehen zu haben. Der Assemblercode im Anhang nimmt 5 Bytes mit den gepackten Daten für 4 Töne entgegen und liefert in 20 Taktzyklen die 4 Notenwerte und die 4 Dauern in 8 Bytes zurück. Das dabei verwendete Packschema ist im Kommentar ganz am Anfang beschrieben. Ich habe den Code nicht getestet, hoffentlich enthält er trotzdem keine Fehler.
Gast
#5519263
Ich hatte gerade nach Flash-Bausteinen gesucht. 256 KBytes SPI Flash kosten 82 Cent. Für diesen Preis würde ich mir die Bitpackerei ersparen.
Ich denke, das geht auch problemlos mit 8 Bit je Note. Anstelle einer Tondauer würde ich den Notenwert nehmen: 1/1, 3/4, 1/2, 3/8, 1/4, 3/16, 1/8, 1/16 sind 8 Werte, für die man 3 Bits benötigt. Es bleiben 5 Bits für die Note (Tonhöhe) übrig. Das ergibt 32 Tonhöhen, was gegenüber den 38 geforderten zuwenig ist. Die meisten Melodien spielen sich zwischen 1-2 Oktaven ab, also könnte man 30 Tonhöhen verwenden und die Vorletzte als Pause und die Letzte für 8 Steuercodes nutzen: - +1 Oktave - -1 Oktave - Beginn Wiederholung 1-fach - Beginn Wiederholung 2-fach - Beginn Wiederholung 3-fach - Beginn Wiederholung 4-fach - Ende Wiederholung - Ende vom Lied Ebenso könnte man noch eine weitere Note "abzwacken" und damit 8 Laustärkestufen realisieren. Der AVR kann die Steuercodes schnell genug auswerten, so dass die Verzögerung eher im einstelligen Mikrosekunden-Bereich liegt und damit unhörbar ist. Jörg
W.S. schrieb: > Einfach nahtlos die jeweils 10 Bit aneinanderkleben und > fertig. Das Auseinandernehmen geht genauso einfach Man braucht ja nur 4 Fälle zu unterscheiden, dann ist man wieder an einer Bytegrenze.
Gast
#5523703
Peter D. schrieb: > Man braucht ja nur 4 Fälle zu unterscheiden Ich vermute mal, daß das Ausführen dieser Unterscheidungen genauso viel oder mehr an Rechenzeit und Code kostet wie die variable Verschiebung. W.S.
W.S. schrieb: > Ich vermute mal, daß das Ausführen dieser Unterscheidungen genauso viel > oder mehr an Rechenzeit und Code kostet wie die variable Verschiebung. Bei AVRs kostet ein ausgeführter Sprung nur einen Takt mehr als ein nicht ausgeführter, dynamische 16-Bit Shifts hingegen benötigen 5 Takte pro Bit. Bei 16/32-Bittern mit Barrelshifter ist eine Fallunterscheidung jedoch ungünstig und mit tiefer Pipeline und Sprungvorhersage wirds erst recht kompliziert.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.