Artikel "FIFO"

Nop schrieb:
> Da ein Mod beschlossen hat, das zu verschieben, daß Gäste nicht mehr auf
> den Beitrag antworten können, ist die Diskussion damit für mich leider
> beendet. Vielen Dank, liebe Moderation.

War sowieso überflüssig, hätte auch gleich kpl. in den Papierkorb 
verschoben werden können.

Nop schrieb:
> Da ein Mod beschlossen hat, das zu verschieben, daß Gäste nicht mehr auf
> den Beitrag antworten können, ist die Diskussion damit für mich leider
> beendet. Vielen Dank, liebe Moderation.

Es hat mit "Projekte und Code" einfach gar nichts zu tun. Da war es 
ursprünglich hingerotzt worden.

Wie man das in Software macht weiß ich nicht, aber in Hardware gibt es 
drei Fälle:

- Im gleichen Takt wird aus dem FIFO gelesen und geschrieben. Das ist OK 
und da kann der FIFO auch gerne voll sein.

- Es wird nur gelesen. FIFO darf nicht leer sein.

- Es wird nur geschrieben. FIFO darf nicht voll sein.

Man muss jedenfalls keinen Speicherplatz verschwenden.

Wenn hier etwas hingerotzt ist, dann der Artikel .)

Gustl, danke.

Ok, ich gebe zu, das int free... reicht nicht aus. Im Gegensatz zu 
anderen hier habe ich kein Problem damit Fehler zuzugeben :)

Aber so geht es tatsächlich, ohne ein Element zu verschwenden:


#define BUFFER_FAIL     0
#define BUFFER_SUCCESS  1

#define BUFFER_SIZE 2

struct Buffer {
  uint8_t data[BUFFER_SIZE];
  uint8_t read; // zeigt auf das Feld mit dem ältesten Inhalt
  uint8_t write;
  uint8_t count; // zähler <!--- NEU
} buffer = {{}, 0, 0};

//
// Gibt an wieviel Platz im Puffer ist
//
//
uint8_t BufferAvailable(void) {
  return BUFFER_SIZE - buffer.count;
}

//
// Stellt 1 Byte in den Ringbuffer
//
// Returns:
//     BUFFER_FAIL       der Ringbuffer ist voll. Es kann kein weiteres 
Byte gespeichert werden
//     BUFFER_SUCCESS    das Byte wurde gespeichert
//
uint8_t BufferIn(uint8_t byte)
{

  if (BufferAvailable() < 1) return BUFFER_FAIL; //Voll

  buffer.data[buffer.write] = byte;

  buffer.write++;
  if (buffer.write >= BUFFER_SIZE)
    buffer.write = 0;

  buffer.count++;

  return BUFFER_SUCCESS;
}

//
// Holt 1 Byte aus dem Ringbuffer, sofern mindestens eines abholbereit 
ist
//
// Returns:
//     BUFFER_FAIL       der Ringbuffer ist leer. Es kann kein Byte 
geliefert werden.
//     BUFFER_SUCCESS    1 Byte wurde geliefert
//
uint8_t BufferOut(uint8_t *pByte)
{
  if (buffer.count == 0)
    return BUFFER_FAIL;

  *pByte = buffer.data[buffer.read];

  buffer.read++;
  if (buffer.read >= BUFFER_SIZE)
    buffer.read = 0;

  buffer.count--;

  return BUFFER_SUCCESS;
}

Und bevor jetzt jemand schreit, daß der Zähler auch Platz braucht: 
Stimmt!
Aber Ringpuffer werden auch für größere Elemente als Bytes verwendet.

Bitte tut euch selbst den Gefallen und korrigiert den Artikel, oder fügt 
zumindest eine Info hinzu.
Vor allem dieser oben erwähnte wirklich fürchterliche Kommentar sollte 
raus.

> Bitte tut euch selbst den Gefallen und korrigiert den Artikel, oder fügt
> zumindest eine Info hinzu. Vor allem dieser oben erwähnte wirklich
> fürchterliche Kommentar sollte raus.


Der steht im Wiki - was hindert Dich daran, das selbst in Ordnung zu 
bringen?

Du hast Deine "Kritik" in "Projekte & Code" abgesetzt, da hat sie 
schlichtweg nichts verloren. Hättest Du sie in "Smarthome" abgesetzt, 
oder in "Analoge Elektronik", sähe das nicht anders aus.

"Wiki":War mir nicht bekannt. Ich überlasse das trotzdem lieber euch.


Bitte nenne mir eine Rubrik die besser passt, dann poste ich das nächste 
mal dort. Das "Offtopic" der richtige Ort ist - darauf muss man erstmal 
kommen.

Frank K. schrieb:
> Das "Offtopic" der richtige Ort ist

Dass man in diesem Fall dass mit Doppel-s schreibt, hättest du aber 
durchaus wissen können...

Frank schrieb:
> Welcher Anfänger hat den Artikel "FIFO" verbrochen ?

1. du plenkst. https://de.wikipedia.org/wiki/Plenk
   Bitte stell das ab.

2. ein Wiki ist ein Wiki ist ein Wiki. Artikel werden nicht dadurch
   besser, daß jemand (s)einen Rant ins Forum kotzt, sondern dadurch
   daß sie korrigiert werden. Klick dir einen Account (hast du wohl
   mittlerweile?) und korrigiere den Artikel. Fertig.
   Damit ist allen Beteiligten besser gedient.

PS: falls es Diskussionsbedarf zu einem Artikel im Wiki gibt: dafür gibt 
es extra den Link "Diskussion" im linken Menu unter "Dieser Artikel"

...mich verstört auch die Tatsache, dass die Implementierung mit sperren 
der Interrupts empfohlen wird.

Bei geschickter Programmierung ist das überhaupt nicht notwendig, da man 
das Update der Pointer atomar mit einer Zuweisung am Ende machen kann.

Die Variante mit dem Counter ist dann allerdings nicht möglich, da die 
"++" Operation nicht zwingend atomar ist.

Unbekannt U. schrieb:
> Das will ich sehen!

Mit Gottvertrauen geht das ;-)

Wer langeweile hat kann ja den Code hier ins wiki packen:

1

//FIFO Zustandsvariablen

2

static struct fifo_vars fifo1_tx;

3

4

//FIFO Speicherbereich

5

static char buf_fifo1_tx[FIFO_SIZE];

6

7

fifo_init(fifo1_tx, buf_fifo1_tx, FIFO_SIZE, uart_nbr, 1);

Markus M. schrieb:
> da man das Update der Pointer atomar mit einer Zuweisung am Ende machen
> kann.

Atomare 16-Bit-Operationen auf einem 8-Bit-µC?

Das ginge allenfalls, wenn nicht mit Pointern, sondern Array-Indices 
gearbeitet würde, und diese nur 8 Bit groß sind, das Fifo also maximal 
256 Einträge enthalten dürfte.

Oder der Compiler müsste wissen, daß er die Pointer zwingend in einem 
16-Bit-Indexregister des µCs vorzuhalten hat, damit er sie atomar 
speichern kann. Welcher Compiler aber weiß etwas von atomaren 
Operationen und den interessanten Auswirkungen von Interrupts?

Frank schrieb:
> Verrate mir mal, warum man in ein Array daß zwei Elementen Platz
> bietet,
> keine zwei Elemente schreiben kann...??

Aus Performancegründen wird lediglich mit Head und Tail Indizes 
gearbeiten. Dafür nimmt man gerne den einen verschwendeten Spot in Kauf. 
Siehe bspw. die Implementierung von boost::lockfree::spsc_queue.

Rufus Τ. F. schrieb:
> Markus M. schrieb:
>> da man das Update der Pointer atomar mit einer Zuweisung am Ende machen
>> kann.
>
> Atomare 16-Bit-Operationen auf einem 8-Bit-µC?
>
> Das ginge allenfalls, wenn nicht mit Pointern, sondern Array-Indices
> gearbeitet würde, und diese nur 8 Bit groß sind, das Fifo also maximal
> 256 Einträge enthalten dürfte.

Ja, genauso tut es doch der Code hier im Beispiel. Es wird uint8_t 
verwendet. Ich nahm jetzt mal diese Implementierung als Ausgangspunkt, 
auch wenn Pointer ggf. effizienter sind.

Auf einem 32 Bit Controller sollte das ja kein Problem sein.

Wenn man beim Schreiben so vorgeht:

- Wert in das aktuell referenzierte Byte im FIFO schreiben
- FIFO Schreibpointer updaten (Voraussetzung: atomar)

Und beim Lesen so:

- Wert aus dem aktuell refrenzierten Byte aus dem FIFO lesen
- FIFO Lesepointer updaten (Voraussetzung: atomar)

Müssen KEINE Interrupts gesperrt werden.