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
Bin ich eigentlich der einzigste der sowas benötigen würde? Je nach rückmeldung implementiere ich es schöner
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.
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
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
@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....
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.
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.
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
""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 !!!
>> ""Peter und ich sind Profi Entwickler, ... > Was muß ich machen, um das auch zu werden ? Davon leben könnnen...
>> 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.
@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.
@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
@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
> 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.
"Sonst werden die Codeschnipsel noch in der Luft zerissen bevor es ein Blatt auf den Boden der Tatsachen geschafft hat." Sehr, sehr klug !
@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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.