Einzelnes Bit im RAM schreiben oder lesen

>Wenn ich einen Zeiger hätte,
>der 5 Bit weit zeigt, wäre das Problem zu lösen.

Sowas gibt es nicht.

ArduStemmi schrieb:
> Ich möchte möglichst viele 5 Bit breite Datensätze speichern. Bisher
> habe ich im RAM ein Byte Array (uint8_t Daten[1024]) angelegt und in
> jedem Byte einen 5 bit breiten Datensatz gespeichert.

Pack deine Datenbits in 40Bit große Datenblöcke. Dann wird alles gut.

das klingt doch nicht wirklich kompliziert.
Dafür würde ich einfach mal in einem C Forum fragen oder Pascal!
Ja Pascal :-) klingt jetzt komisch ist aber so, die Leute dort sind 
meist extrem Hilfreich, und können Dir den richtigen Denkanstoß geben
Ich hätte da schon eine Idee, weiß aber auch nicht wie das geschickt 
umgesetzt wird.
Hier wirst Du nur hören, geht nicht, gibts nicht oder kauf Dir ein Buch 
:-)

Das mit den 4 Bit klingt schonmal gut :-) Ich dachte eher an fortlaufend 
sammeln und sobald 8 Vollständig sind schreiben oder so
Gibt sicher noch etliche andere schnelle Lösungen

bzw 10 bit splitten in 5 und dann warten bis das nächste 8er Paket 
kommt..jeder der hier jetzt wieder rummaulen will, soll erstmal 
überlegen, dann versteht er wie ich es meine

meine 8 Bit splitten.egal :-)

Versuch einmal
http://www.c-howto.de/tutorial-strukturierte-datentypen-bitfelder.html
mit 8 Member a 5 Bit als packed und schau was der Compiler daraus macht. 
Besser wird das von Hand auch nicht. Dann kannst du entscheiden: 
Speicher vs. Geschwindigkeit.

>Dann kannst du entscheiden: Speicher vs. Geschwindigkeit.

Wenn man dann noch einen ATMeg1284 mit 16kB RAM nimmt
fällt die Wshl nicht mehr ganz so schwer. Oder gleich
einen Cortex-M4;) Der wäre mit per Timer getriggertem
DMA sowieso besser geeignet für einen LA.

Tom Thomsen schrieb:
> Pack deine Datenbits in 40Bit große Datenblöcke. Dann wird alles gut.

Das klingt gut, aber wie mache ich 40 bit große Datenblöcke?

Ja! Aber wie greife ich auf Bit 0, 5, 10, ... 35 zu?

Du verschenkst 3072 Bit wenn du 8 Bit Variablen verwendest.

Ist ja beeindruckend.

Bist du dir vollkommen sicher, dass sich dafür der Thread überhaupt 
gelohnt hat, geschweige denn das Programmieren und der 
Performanceverlust durch die Bitoperationen?

Das ist richtig!

Einer der wichtigsten Gründe, warum ich mich mit Mikrocontrollern 
beschäftige, ist das damit verbundene Lernen! In Wirklichkeit brauche 
ich gar keinen Logicanalyzer! Aber ich wollte mich mal mit der Sache 
umfassend beschäftigen. Also das komplette Programm: Hardwareentwurf und 
Basteln, Mikrocontroller programmieren und PC-Programm mit allerlei 
Schnickschnack schreiben!

In diesem Zusammenhang kam mir die Frage, ob man den RAM nicht Bit für 
Bit beschreiben und lesen kann!

Das geht scheinbar nicht ohne aufwendiges Bitgeschiebe (also viel Zeit, 
naja im Mikrosekundenbreich viel) Wieder was gelernt!

Ich werde von fünf auf vier Kanäle wechseln und kann dann 2048 Samples 
speichern!

Ich habe übrigens bei 16 MHz auf 800 kHz  samplingrate (entspricht 1,25 
Mikrosekunden Samplingtime)  gebracht! Passt ganz genau, weil es muss ja 
ein ganzzahliges Vielfaches von 0,0625 Mikrosekunden sein! Ach ja! 
Geeicht ist es nicht! Es ist so genau wie der Quartz taktet! Für meine 
Anwendung ausreichend!

Und Spaß macht das!

Danke für Deine Bemühungen! Du hast natürlich Recht! Für 800 kHz 
ungeeignet! Aber für Samplingrates kleiner 100 kHz könnte es gehen! Ich 
werde das mal testen!

Fuer etwas aehnliches: 4 10 bit AD-gewandelte Werte in 5 Bytes
zu packen habe ich mir fuer die Midrange PICs (12F675/683, 16F684)
mal eine Assemblerroutine programmiert.
Die kann ich dann bequem vom Compiler aus aufrufen und
brauch das widerliche Geschiebe nicht in C zu formulieren.

Die Routine zum "Einpacken" und zum "Auspacken" ist lustigerweise
dieselbe. (Die Speicherbereiche auf denen gearbeitet wird,
natuerlich nicht.)

> Einer der wichtigsten Gründe, warum ich mich mit Mikrocontrollern
> beschäftige, ist das damit verbundene Lernen!

Dann mach mal.

Mehr als ein wenig Zeit und "Brain" braucht es nicht.

ein anderes Beispiel

1

struct set_of_eight          // 5 bytes

2

{

3

    uint8_t first :5;

4

    uint8_t second :5;

5

    uint8_t third :5;

6

    uint8_t fourth :5;

7

    uint8_t fifth :5;

8

    uint8_t sixth :5;

9

    uint8_t seventh :5;

10

    uint8_t eigth :5;

11

}__attribute__((packed));

Falk B. schrieb:

> Eben. Man sollte nicht den Schinken nach der Wurst werfen.

Das sagen die Hochsprachler immer.

Und genau deswegen merkt man von dem Leistungszuwachs der Hardware in 
den letzten Jahrzehnten auch so gut wie garnix. Alles wurde in immer 
tieferen Schichten von in Hochsprachen geschriebenen Abstraktionen 
versenkt...

Das klappte in den 80ern, 90ern und auch in den 00er Jahren noch 
ziemlich gut. Aber seitdem etwa ab 2008 das Moore'sche Gesetz doch ein 
wenig in's Hinken gekommen ist, merkt man doch sehr deutlich, dass 
dieser Weg letztlich in den Abgrund führen wird, ja führen muss.

Das Lustige ist, dass ausgerechnet eine Sprache, die das Prädikat 
"Hochsprache" eigentlich garnicht verdient, den Weg in den Abgrund 
geebnet hat. Und diese Sprache heißt "C". Und sie wird wohl auch bis zum 
bitteren Ende signifikant beteiligt sein...

Es gibt verschiedene Arten es zu realisieren, und es spricht auch nichts 
dagegen mehrere parallel zu implementieren.
 z.B.
 -  Einfach die bits verschwenden, dafür maximale Samplerate
 -  den mode nur 4 Bits zu speichern, die dann in ein Byte zu packen, 
fehlt ein bit, aber doppelte länge, evt etwas langsammer
 - 8 Bytes auf einmal einlesen, einlesen b1 und b2, 4+4 bit zusammen 
packen wegschreiben, das 5 bit in ein anderes byte reinschieben, nach 8 
spamples auch das wegschreiben.
 - Einlesen, gucken ob der Wert identisch mit dem vorherigen, dann einen 
Counter zählen, bis 3 Bit, Die drei Bit werden dann in den freien Bits 
abgelegt.
 - wie vorher nur das die Wiederholung im Extrabyte gespeichert wird 
oder die 3 Bit noch mitbenutzt, damit kann man je nach Signal lange 
Aufzeichungsdauer erreichen.

 Später beim Benutzen sucht man sich den Mode aus, den man braucht hohe 
Samplingrate oder lange Aufzeichung. Beim überprüfen von seriellen 
Bussen reicht oft 2 oder 3 Bit.

 Wichtig ist nur das beim Einlesen jedes Sample den gleichen Abstand zum 
nächsten hat, da sonst das Timing nachher nicht stimmt. Bei Auswerten 
hat man Zeit und muss nicht so tricksen. Wenn man eine sehr effektive 
Einleseroutine haben will, kann man da schon einiges an Zeit 
reinstecken.

@ArduStemmi

Das könnte man doch mit einer Hard-/Softwarekombination lösen.

Beim LA willst Du ja nur wissen ob am Messpunkt zum Zeitpunkt x L oder H 
Pegel anliegt. Du brauchst also einen Puffer in welchen der Pegel 
entsprechend Deiner gewünschten Samplingrate eingeschrieben wird. Für 
sowas verwendet man normalerweise ein Schieberegister. Die Daten werden 
hierbei bei jedem Sampleimpuls in das Schieberegister seriell 
eingeschrieben und stehen nach 8 Samples an den Ausgängen des Registers. 
Jetzt kann man das Register auslesen und damit ein 8 Bit breites 
Datenwort, welches man nun als Byte speichern könnte. Dann werden wieder 
8 Samples eingelesen und das Register ausgelesen. Das Auslesen des 
Registers muß natürlich zwischen 2 Samples passieren.
Du brauchst natürlich für jeden Kanal ein Register. Das Einschreiben in 
die Register wird mit dem gleichen Impuls für alle Register ausgelöst, 
also für alle Kanäle synchron.

So würde ich das realisieren. Nachteil es braucht natürlich zusätzliche 
Hardware. Vorteil die Anzahl der Kanäle kann sehr groß gewählt werden, 
allerdings geht das auf Kosten der Samplerate, da ja alle Register nach 
jedem 8. Sample zwischen 2 Samples gelesen werden müssen.

Ist nur mal so als Denkanstoß gedacht und erhebt keinen Anspruch auf 
Perfektion.


Zeno