mikrocontroller.net

Forum: Compiler & IDEs Dynamische Größe von Fifo Rinpuffer


Autor: Ulrich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich habe mehrere Fifos(ca. 4) welche zusammen ca. 256bytes verbrachen
dürfen. Jeder einzelne soll aber maximal auf 128bytes zugreifen sollen.
Gibts da irgendwelchen Input? Falls es nix gibt, würde ich es so
implementieren (jemand interesse da mitzuhelfen?), das man es einfach
überal reinbauen kann....

PS: Jeder der jetzt postet "ich soll suchen", dem bin ich dankbar. Da
ich absolut nix gefunden habe und mich freue wenn jemand Links kennt
(und hier postet) die ich nicht kenne.

Mfg
Ulrich

Autor: Ulrich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bin ich eigentlich der einzigste der sowas benötigen würde?
Je nach rückmeldung implementiere ich es schöner

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wozu soll so etwas gut sein ?

Eine MC Anwendung soll doch immer funktionieren, d.h. auch im worst
case. Entweder alle Maximalwerte ergeben 256 (z.B. 4 * 64) oder das
ganze ist witzlos. Ich möchte jedenfalls nicht meine MC-Anwendungen
ständig neu booten müssen.

Deshalb lege ich für jede Schnittstelle maximale Paketlängen fest,
deren Überschreitung durch ein entsprechendes Protokoll verhindert wird
(z.B. überlange Pakete werden verworfen). Dabei ist es völlig
unerheblich, wenn im worst case alle gleichzeitig auftreten.


Peter

P.S.:
Auch würde der zusätzliche Verwaltungsaufwand die mögliche Einsparung
bei weitem übertreffen oder das ganze wird arschlahm durch die ständige
Umsortiererei. In jedem Fall wird es ein Codemonster welches nicht worst
case sicher ist.

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter hat absolut Recht, ich sehe auch keinerlei praktischen Nutzen
solcher pseudo-dynamischer FIFOs.

Einzigste Ausnahme sind dynamisch erzeugte FIFO Buffer zb. per Malloc()
oder so. Diese sind zb. notwendig als Buffer bei einem Dateizugriff um
die Prozessorlast besser zu gewichten. Nun hat man ja nicht zu jedem
Zeitpunkt gleich alle Dateien geöffnet und ein solcher FIFO macht ja
nur Sinn bei einer geöffneten Datei. Also wird der FIFO direkt mit dem
Dateihandle verknüpft und existiert nur dynamisch solange eine
spezifische Datei geöffnet ist. Das ist jetzt nur ein Beispiel für
einen solchen Buffer, da ja bei Dateizugriffen ein FIFO eher unüblich
ist.

Aber ansonsten sehe ich für einen statischen aber in der Größe
dynamischen FIFO keinerlei Nutzen.

Gruß Hagen

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, es gäbe da eine sinnvolle Anwendung solcher FIFOs. Angenommen man
hat über eine Schnittstelle vrschiedene Protokolle laufen die auch noch
unterschiedliche Datenraten benötigen. Dann könnte ich mir vorstellen
das ein solcher pseudo-dynmischer FIFO Sinn machen könnte.
Ich würde dann aber die FIFOs denoch statisch programmieren und sie
dann so groß machen das das Worstcase Protokoll ohne Probleme läuft.
Denn im Worstcase benötigst du dann sowieso einen großen FIFO und
dieser benötigt entsprechende Resourcen. Dh. mit der geplanten Auswahl
des protokolles steht von Anfang an auch der Worstcase fest und somit
der FIFO und der Resourcenverbrauch. Also auch in diesem Falle würde es
zwar Sinn machen aber nicht wirklich pratischen Nutzen haben.

Gruß Hagen

Autor: Ulrich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hagen,
genau für sowas wollte ich es anwenden. Ich will per USB (super
schnell) auf verschiedene I2C Devices zugreifen.
Über USB kommen viele Daten gepulst an, welche in einem Fifo
gespeichert werden müssen. Sobald die USB-Übertragung ausgewertet ist
müssen die Daten per I2C übertragen werden und die Rückmeldungen müssen
in einen 2. FiFo rein und dann per USB wieder zurück.
Keines der Fifos ist gleichzeitig voll, aber immer abwechselnd.
Ist es da wirklich nicht sinnvoll den Speicherbedarf dynamisch zu
machen?
Natürlich gäbe es eine Maximalgrenze und wenn die erreicht wird werden
keine Daten mehr angenommen...

Aktuell habe ich folgendes Fifo fast 1:1 implementiert:
http://www.roboternetz.de/wissen/index.php/FIFO_mit_avr-gcc
Das benötigt 7 Bytes + Fifogröße.

Wenn ich das mal mit nur 2 Puffern rechne(der einfachheit wegen..)
komme ich bei 128Byte Peak pro Fifo auf 270bytes Insgesammt.

Bei meiner angedachten Lösung brauche ich 8 bytes + fifogröße * 1,125
pro Fifo.
Das macht dann bereits bei 160Bytes (Ein Fifo 128Byte das andere
32Byte) Ein Platzbedarf von nur noch 196Byte.

Ich denke ich buddel den Thread hier wieder raus wenn ich eine fertige
Lösung habe......sonst muss ich mir noch per pessimismus anhören....

Autor: Ulrich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe nun mein Dynamisches Fifo fertig.
Es benötigt 500byte mehr Speicher im Flash.
Damit kann man z.B.:
4Fifos mit unterschiedlichen Mindeskapazitäten anlegen.


Kann sich jemand vorstellen das er sowas braucht?
Wenn ja dann würde ich es eventuell "schöner fertig" machen.

Autor: Egon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kann mir leider nicht vorstellen, dass jemand anderes so etwas auch
braucht. Lies weiter oben, dann siehst Du, dass die Leute lieber
statisch denken und eher nach mehr Speicher schreien, als ihn
effektiver auszunutzen.
Allein wenn Du FIFO-Programme ansiehst, wirst Du festellen, dass immer
2er Potenzen als Größe verwendet werden, weil die Programmierer
maschinengerecht programmieren und nicht bedarfsorientiert. Anstatt 80
Byte werden dann 128 Byte für einen Puffer programmiert.

Meine Meinung.

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein wichtiges Merkmal stabiler Softwareentwicklung ist Simplizität,
sprich Einfachheit. Das ist stabil, einfacher zu verstehen und ganz
wichtig es verbraucht die wenigste Arbeitszeit. Peter und ich sind
Profi Entwickler, Peter in Hardware und Software und ich nur in
Softwareentwicklung. Daher spielen diese Faktoren die größte Rolle,
besonders die Arbeitszeit da das eben Profit bedeutet.

>>Lies weiter oben, dann siehst Du, dass die Leute lieber
>>statisch denken und eher nach mehr Speicher schreien, als ihn
>>effektiver auszunutzen.

Nun das ist zu einfach gesehen. Denn 500 Bytes FLASH zusätzlich für par
FIFOs ist eine Menge mehr an Resourcen, an Speicherresourcen. Sogesehen
ist eben ein statischer FIFO nicht nur Speicher-optimaler sondern auch
einfacher und effizienter. Ein Programmierer der in diesem Falle
"statisch" denkt macht nichts falsches.

>>@Hagen,
>>genau für sowas wollte ich es anwenden. Ich will per USB (super
>>schnell) auf verschiedene I2C Devices zugreifen.

So wie du dein problem umschrieben hast ist dies kein Fall für einen
dynasmichen FIFO. In meinem obigen Posting habe ich versucht quasi eine
Grenze aufzuzeichnen und die dafür notwendigen Bedingung zu definieren.
Hauptmermal sind

- die FIFOs existierten nicht permanent, werden also zb. er bei Öffnen
einer Datei benötigt.
- die FIFOs sind "shared", dh. sie werden in EINEM Hardwarekanal
durch unterschiedliche Software-treiber benutzt.

Keine dieser Bedingungen ist durch deine Problemstellung abgedeckt. Das
heist bei dir existiert die USB-I2C-USB Verbindung permanent, die Größe
der FIFOs richtet sich vorausberechenbar nach der
Geschwindigkeitsdiffernez zwischen USB und I2C und dem festen
Datenprotokoll was darauf läuft.

Es ist durchaus üblich für beide Datenrichtungen auch zwei feste FIFOs
zu benutzen.

Gruß Hagen

Autor: Egon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
""Peter und ich sind Profi Entwickler, ...

Was muß ich machen, um das auch zu werden ?

""Denn 500 Bytes FLASH zusätzlich für par FIFOs ist eine Menge mehr
an Resourcen,...

Das ist doch Quatsch !

Fazit: Was Ulrich gemacht hat finde ich prima !!!

Autor: Tastendrücker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> ""Peter und ich sind Profi Entwickler, ...

> Was muß ich machen, um das auch zu werden ?

Davon leben könnnen...

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Denn 500 Bytes FLASH zusätzlich für par FIFOs ist eine Menge
>> mehr an Resourcen,...

> Das ist doch Quatsch!

It depends.  Flash-ROM ist sehr viel billiger als RAM (das ist der
Grund, warum selbst die größten AVRs nur 8 KB RAM haben).
Insofern kann es auf einem ATmega16 durchaus 500 Bytes ROM Wert sein,
wenn man damit 250 Bytes RAM einsparen kann.  Hängt halt immer
davon ab, an welcher Ecke man gerade Resourcenengpässe hat.

Autor: Egon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Tastendrücker, es gibt so viele Täuscher, die auch alle Leben :-) look
at me.

@Jörg, danke. Meist ist doch RAM zu knapp; und wer hat denn schon
einmal wirklich den kompletten FLASH-Speicher mit Programmcode
ausgereizt, dass nichts mehr ging ? RAM könnte man nie genug haben.

Manchmal habe ich den Eindruck, bloss alles so zu machen wie vor 30
Jahren, das kann nicht verkehrt sein. Man findet immer Gründe, warum
etwas nicht gehen soll (beste Ausrede: braucht man nicht); mal was
Neues zu machen finde ich viel interessanter.

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Ulrich,

zeig doch einfach mal den Code.

Funktioniert er auch, wenn einige FIFOs in Interrupts benutzt werden ?

Die 500 Byte Flash müssen nicht unbedingt stören, Hauptsache die
CPU-Last steigt nicht zu sehr.

Wieviel RAM wird denn zusätzlich für die Verwaltung benötigt ?


Bei Paketübertragung benutze ich lieber einen Linearpuffer, dann kann
man die Pakete direkt im Puffer parsen bzw. erzeugen, da kein Wrap
around möglich. Der Puffer sollte dann aber schon 2 Pakete fassen
können.
Nachdem 1 Paket geparst wurde, werden alle zwischenzeitlich empfangenen
Bytes wieder an den Pufferanfang gestellt.


Peter

Autor: Ulrich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@all(die die Idee gut finden):
Im Prinzip habt ihr alle Recht....

@Peter/Hagen:
Ich mache dies ja nicht beruflich sondern aus Spaß am Hobby. Wenn man
es aus der beruflichen Perspektive betrachtet macht es möglicherweise
schon Sinn bei altbewährten Sachen zu bleiben. Man geht keinerlei
Risiken ein. Lieber einen größeren Controller als mehrere Stunden
Arbeit. (Arbeitszeit ist in Deutschland das teuerste habe ich mir sagen
lassen)
Aber es hat mich schon erschrekt wie negativ ihr über etwas neues
gleich denkt. Ich hätte von Peter exact das Gegenteil erwartet.
Neue Ideen Inovationen usw...


@Hagen:
Nochmal zum Vorteil den ich in der dynamisierung sehe....:
Ich habe USB. Ich kann damit 254bytes pro ms an meinen Mikrocontroller
senden oder empfangen....Diese Daten müssen zwischengespeichert werden
können. Also benötige ich statisch gesehen 256Byte für das
Empfangs-Fifo. Diese Daten müssen nun an verschiedene I2C-Devices über
einen 100Khz gesendet und von dort auch wieder Daten empfangen werden.
Diese Daten müssen nun gespeichert werden bis sie wieder per usb
abgeholt werden....nochmal 256Byte für den Sende-Fifo. Macht allein für
diese 2 Fifos 512bytes an Speicher. Diese Fifos sind immer abwechselnd
gefüllt. Wo denkst du mache ich mit meiner Lösung was falsch? Wenn du
das so ließt, dann kannst du doch nicht bei folgender Aussage
bleiben?:
>> So wie du dein problem umschrieben hast
>> ist dies kein Fall für einen dynasmichen FIFO.

@Peter:
Der Code Funktioniert nicht wenn die Zugriffe von verschiedenen
Interrupt Ebenen erfolgt.
Der einzigste Interrupt ist der int0 alle anderen Interrups werden in
der main() gepollt.

Aktuell benötigt jedes Fifo 9Bytes für die Verwaltung.
Dann gibts halt ein Rießen-array in dem Speicherblöcke angelegt sind.
Jeder Speicherblock hat 1Byte an Verwaltungsoverhead. Das heißt das ich
für 512Bytes Netto in 16Blöcken 528Bytes Brutto benötige.

Ich kann die Daten nicht direkt auswerten. Das sieht die
usb-Implementation so nicht vor.

Veröffentlichen wollte ich den Code eigentlich erst, mit dem Rest von
dem Projekt.
Bei mir läuft der Code ganz gut und er wird gerade von einem Bekannten
der sich auch mit AVRs auskennt in den nächsten Tagen getestet.

Eins verspreche ich dir, ich poste den Code sicherlich nicht hier,
solange noch die Möglichkeit besteht dass da ein grober Fehler drin
ist.
Sonst werden die Codeschnipsel noch in der Luft zerissen bevor es ein
Blatt auf den Boden der Tatsachen geschafft hat.

Wenn der Code die Schönheitsanforderungen entspricht und ich sicher bin
das er passt veröffentlich ich ihn schon...


Mfg
Ulrich

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wenn man es aus der beruflichen Perspektive betrachtet macht es
> möglicherweise schon Sinn bei altbewährten Sachen zu bleiben. Man
> geht keinerlei Risiken ein. Lieber einen größeren Controller als
> mehrere Stunden Arbeit.

Naja, "it depends".  Wenn man für drei oder 10 Stück eines
Miniprojekts nachdenkt, wird das Projekt auf Grund der zu
investierenden Arbeitszeit vermutlich schon so teuer genug, dass man
(falls nicht andere Gründe wie Strom- oder Flächenverbrauch dagegen
sprechen) gleich den größten verfügbaren Controller benutzen kann.
Für die Entwicklungsarbeit braucht man sowieso große Controller (Platz
für Debug-Informationen, weniger Stress, gleich alles irgendwie in den
progmem zu schieben, JTAG).  Der Preis des Controllers oder Boards
spielt keine Geige, zumindest nicht beim 8-Bit-AVR.  Da man für
ungenutzte Resourcen auch kaum Rabatt bei Atmel bekommen wird, braucht
man auch nicht mehr optimieren, wenn man das Ziel (mit der notwendigen
Reserve für spätere Bugfixes) erreicht hat.

Wenn man dagegen für mehrere tausend Stück aufwärst denkt, ändert sich
das.  Wenn man für mehrere hunderttausend Stück aufwärts denken soll,
ändert sich das drastisch, und man wird mit jedem Cent geizen wollen.

Für Bastler sind die Perspektiven sehr verschieden.  Solange man
Schüler oder Student ist, hat man oft viel Zeit und wenig Geld.  Dann
kommen Dinge wie Igor PlugUSB raus: guter Nutzen (unter Beachtung der
Randbedingungen) für wenig Geld.  Ziemlich viel Zeit in die
Entwicklung investiert.  Muss man das Hobby später neben Job und
Familie mit 1...3 Stunden am Abend betreiben, ändert sich die
Perspektive schnell.  Auf EUR 10 für einen größeren Controller
kommt's
dann nicht mehr an, und selbst die kostspielige Anschaffung eines JTAG
ICE Originals könnte sich schon irgendwie lohnen, wenn man damit in
der gleichen Zeit effektiver wird.

Autor: Egon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Sonst werden die Codeschnipsel noch in der Luft zerissen bevor es ein
Blatt auf den Boden der Tatsachen geschafft hat."

Sehr, sehr klug !

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Ulrich

"Sonst werden die Codeschnipsel noch in der Luft zerissen bevor es
ein
Blatt auf den Boden der Tatsachen geschafft hat."


Man könnte es aber auch als Gelegenheit sehen, die Fehler schneller zu
finden.

Nur zerreißen wird hier keiner was, sondern er wird auch begründen, was
seiner Meinung nach daran faul ist.


"Aktuell benötigt jedes Fifo 9Bytes für die Verwaltung."

Das ist schon recht heftig.
Bei FIFOs bis 256 Byte habe ich 2 Bytes Verwaltung, den eingehenden und
den ausgehenden Index und eventuell noch ein Bit für Überlauf. Wobei der
FIFO immer ein Leerbyte enthält (die Indexe dürfen sich ja nicht
einholen).


Wenn ich Dich richtig verstehe, heißt dynamisch nicht eine variable
Anzahl von Bytes, sondern nur Vielfache von 32 Byte.


Peter


P.S.:
Die Postings von Hagen bitte nur ihm zuordnen, ich habe mit ihm nichts
abgesprochen.

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.