THEMA:

KeDaiv schrieb: ..
lese ich ca 4x vom EEPROM.

nur mal so nebenbei, das lesen einer EEPROM Zelle ist für die Zelle nicht schädlich. Nur das schreiben!

Mehr vielleicht morgen, wenn ich wieder die Augen auf habe.

Nils

Sascha Amberger schrieb: "KeDaiv " (Hast du auch einen richtigen Namen?)

Joar, den hab ich auch! Wenn du dir mein Code anschaust, steht der jeweils ganz oben, oder sollte zumindest!

Sascha Amberger schrieb: Kinderbelehrungskiste mit Bleistift und Papier

Dazu möchte ich auch kurz nochmal was sagen. Ich habe das bestimmt 3x versucht zu erklären. Wenn man sich das denn immer noch nicht vorstellen kann, dann schnappt man sich halt Zettel und nen Stift. Ich hatte gestern dies kleine Progrämmchen meinem Ausbilder gezeigt. Der ist Dipl.-Ing. in der Informatik der hat sich auch nen Zettel und nen Stift geschnappt. Nachdem er das Prinzip verstanden hatte meinte er auch, das ist ne gut Idee. Besonders bei Ideen, welche von anderen kommen, geht es meistens nicht anders. Weil einem einfach das Konzept dahinter fehlt. Denn keiner kann wissen, wie der andere gedacht hat!
Jedoch wenn man das nicht verstehen möchte. Denn will man das einfach nicht.

Nils Canditt schrieb: nur mal so nebenbei, das lesen einer EEPROM Zelle ist für die Zelle nicht schädlich. Nur das schreiben!

Genau deswegen versuche ich so wenig wie möglich zu schreiben! Mir ist gestern jedoch noch was aufgefallen. Zum ersten mache ich gerade einen kleinen Vergleich falsch. Hab ich schon behoben und werde ich nach der Arbeit hoch laden. Zum anderen kann ich evtl noch einige Lesezyklen sparen, weil ich eine Speicherzelle doppelt lese. Jedoch muss ich erstmal schauen, ob das so geht, wie ich es mir denke.

Dann euch ein schönen Tag!
mfg
KeDaiv

Ich wollte ja eigentlich nichts mehr darueber schreiben. Aber es liegt nicht am Verstaendnis Deiner Idee mit diesem Ringpuffer. Ich hab das verstanden, das muss ich mir nicht aufmalen. Leider verstehst Du auch nicht was ich Dir sagen moeche:

Du brauchst sowas nicht einzubauen, die Software wird dadurch nur unnoetig Fehleranfaellig.

Ich hab mir mal den Code angeschaut, leider konnte ich nix finden was zu einer TPS gehoert.

Andy

Andy Jungmann schrieb: Ich hab mir mal den Code angeschaut, leider konnte ich nix finden was zu einer TPS gehoert.

KeDaiv schrieb: Ich hab es zur Zeit für den PC geschrieben, damit ich es besser Debuggen kann. Auch euch geb ich es so. Da könnt ihr dann testen wenn ihr wollt.

Wie ich schon geschrieben habe. Damit ich es besser Debuggen kann, hab ich es einfach mal nur mit dem GCC kompiliert und nicht gleich mit dem AVR-GCC. Wie auch in meinem Beitrag einen weiter oben, habe ich auch schon n paar kleine Fehler gefunden ( zum glück lag es nicht auf dem µC ).
Ich werde das natürlich noch für den µC anpassen. Jedoch weiß ich nicht, ob ich das noch diese heute und morgen schaffe, weil ich erst noch Doku lesen muss und dann halt schreiben. Also, seid bitte nicht böse deswegen, aber ab und an muss ich auch mal was für meine Wohnung und für mich tun!
Fehleranfällig ist jede Software. Es kommt halt nur darauf an, wie man diese Testet und ich werde den Programmabschnitt ja nicht ungetestet auf den µC hauen. Also von daher mal schauen, wie viele Fehler dadurch entstehen!

Wenn ich es ergebnisorientiert sehe, das heißt Projekt gleich der Entwicklung einer Tauchtanksteuerung in effektiver Weise (zeitlich, ökonomisch, zuverlässig) betrachte, dann sehe ich den Sinn im Puffer (hier) nicht.

Wenn ich das Projekt definiere, als ein Vorhaben, welches mich am Beispiel einer TTS in verschiedene Programmiermöglichkeiten einführt, ich auf modulare universelle Konzepte dabei wert lege, dann halte ich Dein Vorgehen durchaus für logisch. Du lernst Mikrocontrollertechnik samt Programmentwicklung eben von der Pike auf.


(Andere lerne übrigens Modellbau so ... . Wie sagte jüngst jemand? Mit dem größten Aufwand den geringst möglichen Nutzen zu erzielen.)

Irgendwann wirst Du "wissen" bzw. berechnen/überlegen, ob ein universelles Modul zweckmäßig ist oder ob es nicht angepasst (reduziert) werden sollte. Du wirst wissen, dass ein Evalutaionsboard prima ist, jedoch dass es nur den Funktionsnachweis erbringt und kein Prototyp ist.

Vor nun schon vielen Jahren - Jahrzehnten - habe ich mir Aufgaben gestellt wie ich dütt und datt lösen könnte. Vom Zahlensystem bis zum Druckertreiber in Assembler. Ich habe daran gelernt. Und parallel mir Lösungen der Technik angesehen. Sie nachvollzogen, verglichen. Dadurch kann ich auch Lösungen finden, die (derzeit) nicht realisiert werden.

Diesen spielerischen Zugang konnte ich mir damals leisten. Jung, in Ausbildung. Heute geht es nur als Hobby. Oder beruflich: kurz und bündig auf den Punkt gebracht, ohne langes ausprobieren, herumspielen, denn das bezahlt mir niemand und ich muss meinen Bäcker bezahlen.

Meine Erfahrung ist, mir hat der damalige spielerische Umgang geholfen, hilft mir im Hobbybereich heute noch. Zugleich habe ich nicht alle Hobbys zum Beruf gemacht, denn unterm Strich muss etwas herauskommen, s.o.

Liebe Greet-Ings Cornelius

corneliusrufus schrieb: Irgendwann wirst Du "wissen" bzw. berechnen/überlegen, ob ein universelles Modul zweckmäßig ist oder ob es nicht angepasst (reduziert) werden sollte. Du wirst wissen, dass ein Evalutaionsboard prima ist, jedoch dass es nur den Funktionsnachweis erbringt und kein Prototyp ist.

Natürlich werde ich bevor ich final irgendetwas veröffentliche oder hochlade so gut wie möglich testen und schauen. Wenn dann irgend etwas nicht so funktioniert, wie es sollte, dann muss ich mir natürlich ünerlegen, woran das liegt. Ich mache dies in meiner Freizeit. Jedoch auch nach bessten Wissen und Gewissen! ^^
Ich will dann mal hoffen, das euch dies denn auch zukommt!
Wegen dem spielerischen Umgang. Ich bin gerade in der Ausbildung! Mal schauen, was dort noch kommt!

Nachdem ich mich nun rudimentär erstmal an das lesen und schreiben ran gemacht habe, kam ich dort dies WE zu einem gut annehmbaren Ergebnis. Nach mal wieder langer Einarbeitungszeit in das Datenblatt zum EEPROM möchte ich euch mein Ergebnis auch nicht vorenthalten.
Der Puffer oder die Speicherseiten für den EEPROM müssen dann nun diese Woche noch mit aufgenommen werden.
Vorteil von diesem Stückchen Code erstmal.
Ich schreibe Daten, welche auf den EEPROM geschrieben werden sollen erst in einen Puffer (ach, schon wieder einer! ), wenn dies von außen aktiviert wurde. Ein Interrupt kümmert sich dann darum, das sobald der EEPROM bereit ist zu schreiben, die Daten auch rauf geschrieben werden.
Bevor jetzt vlt kommt, das dadurch Daten verloren gehen, möchte ich sagen, das ich so oder so immer warten muss, bis der EEPROM zum schreiben bereit ist. Danach kommen die Daten erst rauf. Dadurch, dass das eigentliche Schreiben( wenn es aktiviert wurde ) durch einen Interrupt geschieht, habe ich den Vorteil andere Sachen zu machen. Sobald der EEPROM bereit ist, werden die anderen Sachen unterbrochen und erstmal geschrieben. Ist dies fertig, wird wieder dort weiter gemacht, wo aufgehört wird.
So. Aber hier nun mal der Code, das es auch noch mal durch eure Augen geht. Wieder einmal, wer Fehler findet, darf sie nicht behalten!
Es wäre dann nett, diese mir zu berichten! ^^
keeprom.c