Frei nach Erik Bartmann: Meine Eeprom-Lösung

Anmerkungen zum Quelltext: Namen werden in Python klein_mit_unterstrichen geschrieben. Ausnahmen sind Konstanten (KOMPLETT_GROSS) und Klassen (PascalCase).

Namen sollten keine kryptischen Abkürzungen enthalten oder gar nur daraus bestehen. Der Name soll dem Leser vermitteln was der Wert dahinter im Programm bedeutet, nicht zum rätseln zwingen. TK kenne ich als Krankenkasse, oder „Tiefkühlkost“, oder als Bleistiftmodell. 🙂

Kommentare sollten entsprechend dem Code eingerückt sein, sonst erschweren die das ablesen der Code-Struktur anhand der Einrückung. Insbesondere wenn da noch so dekorative Trennlinien sind. Zudem macht es mehr Sinn zur Dokumentation der Klasse und Methoden DocStrings zu verwenden. Dafür gibt es die ja.

Es macht keinen Sinn jeder Kommentarzeile noch ein * am Anfang hinzuzufügen. Die werden ja alle schon mit dem Kommentarzeichen eingeleitet.

In den Kommentar/die Dokumentation der Klasse noch mal class und den Klassennamen zu schreiben ist Redundant. Das sieht man ja auch so, sowohl menschliche Leser, als auch Dokumentationswerkzeuge.

Wo die Vorbelegung der Pins erfolgt hat da nichts zu suchen, denn wenn sich das in dem anderen Modul mal ändert, müsste man daran denken diesen Text auch anzupassen. Ähnlich das „write protect“ auf High gesetzt wird ist eine Information die nur darauf wartet vergessen zu werden falls sich das mal ändert.

read_byte() und send_byte() sind Methoden und keine Funktionen.

Das parent-Argument von __init__() wird nirgends verwendet.

data = data ist sinnfrei.

Um if-Bedingungen braucht man keine Klammern setzen.

Statt magischer Zahlen im Code wo die Konstantennamen nur im Kommentar stehen, sollten das tatsächlich Konstanten sein.

affectWEL() ist ein komischer Name für set_write_enable().

Der Satz „liest 'count' Bytes aus 'data_list' ab der Adresse 'index' ins Eeprom“ ist ein bisschen verwirrend.

Grunddatentypen haben nichts in Namen verloren. Den Typen ändert man gar nicht so selten mal während der Programmentwicklung und dann muss man überall im Programm die betroffenen Namen ändern, oder man hat falsche, irreführende Namen im Quelltext. Und statt einer Liste kann man hier auch beliebige Sequenzen verwenden. Sogar ein Wörterbuch könnte man übergeben.

Allerdings ist das keine gute API (leere) Datenstrukturen zu übergeben und zu füllen, statt eine neue zu erstellen als Rückgabewert zu liefern. Selbst wenn man das mit der Datenstruktur zum befüllen macht, ist das schräg die Adresse im EEPROM und den Index in diese Datenstruktur auf diese Weise zu koppeln. Genauso schräg ist das beim Schreiben der Daten. Da würde man einfach nur eine Zieladresse und eine Sequenz mit Bytewerten übergeben, statt index und count auch für die zu sendenden Daten zu verwenden.

wip und wipcount kann man sich sparen wenn man eine for-Schleife schreibt, die mit break abbricht und den else-Zweig zum for für die Ausnahme verwendet.

Insgesamt kann man in der Methode mit deutlich weniger Variablen auskommen und leichter verständlichen Code schreiben.

Ungetestet:

 from time import sleep

import pigpio
from pigpio import HIGH, LOW

DELAY = 0.00001  # in Sekunden.  Eine Halbperiode bei 50 kHz.
#
# Instruktionen.
#
RDSR = 0b00000101  # Read status register.
WREN = 0b00000110  # Write enable.
WRDI = 0b00000100  # Write disable.
WRSR = 0b00000001  # Write status register.
READ = 0b00000011  # Read data.
WRITE = 0b00000010  # Write data.

BP0 = 0b00000100
BP1 = 0b00001000


class EEPStorage:
    """
    Generell liegt das Timing des SLCK-Taktes bei den beiden Methoden
    `read_byte()` und `send_byte()`.
    """

    def __init__(self, sclk, mosi, miso, csen):
        self.pi = pigpio.pi()
        self.sclk = sclk
        self.mosi = mosi
        self.miso = miso
        self.csen = csen

    def send_byte(self, data):
        """
        Schreibe 1 Byte in das Eeprom.
        """
        for _ in range(8):
            self.pi.write(self.mosi, (data & 0x80) > 0)  # Bit an Position 7
            data <<= 1
            sleep(DELAY)
            self.pi.write(self.sclk, HIGH)  # steigende Flanke serieller Takt
            sleep(DELAY)
            self.pi.write(self.sclk, LOW)  # fallende Flanke serieller Takt

    def read_byte(self):
        """
        Lese 1 Byte aus dem Eeprom.
        """
        data = 0
        for _ in range(8):
            sleep(DELAY)
            self.pi.write(self.sclk, HIGH)  # steigende Flanke serieller Takt
            data = (data << 1) | self.pi.read(self.miso)
            sleep(DELAY)
            self.pi.write(self.sclk, LOW)  # fallende Flanke serieller Takt
        return data

    @property
    def status(self):
        """
        Der Wert des Status-Register.
        """
        self.pi.write(self.csen, LOW)
        try:
            self.send_byte(RDSR)
            return self.read_byte()
        finally:
            self.pi.write(self.csen, HIGH)

    @status.setter
    def status(self, value):
        self.pi.write(self.csen, LOW)
        self.send_byte(WRSR)
        self.send_byte(value)
        self.pi.write(self.csen, HIGH)

    def set_write_enable_latch(self, state):
        """
        Das WRITE-ENABLE-Latch setzen.
        """
        self.pi.write(self.csen, LOW)
        self.send_byte(WREN if state else WRDI)
        self.pi.write(self.csen, HIGH)

    def read_sequence(self, address, count):
        """
        Lese `count` Bytes ab `address`.
        """
        self.pi.write(self.csen, LOW)
        try:
            self.send_byte(READ)
            self.send_byte(address)
            return [self.read_byte() for _ in range(count)]
        finally:
            self.pi.write(self.csen, HIGH)

    def write_sequence(self, address, data):
        """
        Schreibe die gegebenen Bytewerte aus `data` an `address` ins Eeprom.
        """
        page_size = 16
        for offset in range(0, len(data), page_size):
            for _ in range(8):
                if not self.status & 0b00000001:
                    break
                sleep(0.1)
            else:
                raise IOError("Write process taking too long")

            self.set_write_enable_latch(True)

            self.pi.write(self.csen, LOW)
            self.send_byte(WRITE)
            self.send_byte(address + offset)
            for value in data[offset : offset + page_size]:
                self.send_byte(value)
            self.pi.write(self.csen, HIGH)

Batucada2 Ich glaube Du verstehst nicht was die Intension ist. Das was angesprochen wurde ist reine Rechtschreibung und ein bisschen Grammatik um es auf eine normale Sprache zu reduzieren. Geschriebener Text sollte halt lesbar sein und geschriebener Code ebenso. Dafür gibt es in Python Konventionen namens PEP8. Das ist sowas wie der Duden für die deutsche Rechtschreibung. Man hält sich daran und schon weiß jeder was im Text gemeint ist ohne den Text mehrmals lesen zu müssen. Klar könnte man sich nicht an die Regeln halten, aber dann würde man sich nicht wundern, wenn Leute das auch ansprechen würden.

Dein Code entspricht nicht den Konventionen, also gibt es keinen Grund einem User, der diesen durcharbeitet und berichtigt, komisch zu kommen.

Anbei mal mein Kommentar:

1) Ich finde gut dass Batucada2 seinen Code hier der Community zur Verfuegung stellt

2) Ich mache das fuer meinen Code in github und dort bekommt man stylistischen bzw formalen Feedback nur wenn man in ein existierendes Projekt einsteigt. Gemaess Helmut Kohl ist "entscheidend was hinten rauskommt".

3) __blackjack__hat sich die Arbeit gemacht den Code durchzusehen und hat sinnvolle Verbesserungsvorschlaege. Ein jeder der den Code hilfreich findet und nutzt kann fuer sich entscheiden ob er das Feedback von __blackjack__ im Code eingearbeitet

Quote from Batucada2

Nein, das ist wirklich kein komischer Name, aber set_write_enable() ist der dümmste Vorschlag überhaupt. WEL bedeutet Write Enable Latch

Ein gutes Beispiel, weshalb man aussagekräftige Namen verwenden sollte, denn ohne diese, macht man sich schnell falsche Vorstellungen beim Lesen des Codes.

Der Interpreter schluckt so ziemlich alles, was man ihm als Namen zu fressen gibt und wenn das dann zueinander passt ist für den alle gut, aber als menschlicher Leser versteht man eben nicht alles sofort oder es kommt zu Missverständnissen wie hier. Genau deshalb gibt es PEP8. Nur weil sich nicht jeder daran hält ist das noch lange kein Grund das nicht zu tun. "Nur weil alle von der Klippe springen, muss man das ja nicht auch machen." Hat Mutti früher öfter mal zu mir gesagt.

Wenn man so Wehement auf PEP8 besteht dann sollte man auch die Ungarische Notation für Variablen und Konstanten zwingend nutzen.
Andernfalls ist beim lesen des Code nicht ersichtlich um was für eine Variable es sich handelt.
Wenn schon, denn schon.
jm2ct

Das ist doch in jedem Thema das gleiche, was du vondir gibst. Es ist recht einfach, behalte dein Code für dich oder zieh was nützliches aus der Kritik.
Oder *frage* nach Optimierungspotential aber erwarte es nicht stillschweigend.

Das sind so unnötige, wiederkehrende Diskussionen in deinen Themen, aber ich weis, es liegt nicht an dir.🧐

Nochmals, mir geht es nicht um den Inhalt, bzw. Zweck des Codes, sondern um die Lesbarkeit.

WäN iCH seetZE inn Dihser Art SchRAibe, dan lähsd sISch dAs aUCh sClÄChd lähSEn uhNd värSTEen.

Der_Imperator Wo aus PEP8 leitest Du das denn ab? Und warum ist ungarische Notation da zwingend? Und ja sicher auch nicht bei jedem Namen, falls das die Bedeutung von „zwingend“ sein sollte, denn nicht nur statische Prüfwerkzeuge, sondern auch menschliche Leser sind zu einem gewissen Grad zu Typinterferenz fähig. Ansonsten macht man das ja auch tatsächlich. Also die echte ungarische Notation, die im Namen die Bedeutung hat, nicht einen (Grund)daten(typ).

Und wer wirklich konkrete Typen im Quelltext sehen will pappt das nicht an den Namen, sondern schreibt Typannotationen. Dafür sind die ja da.

Batucada2 Ich habe den Code inhaltlich verbessert. Und zum Beispiel die schräge API durch eine sinnvoller benutzbare ersetzt, die nicht unsinnigerweise die Adresse im EEPROM an den Index in der Sequenz koppelt, was in der Benutzung zu umständlichen Code führt wo ganz bestimmt mehr als ein Leser einen WTF‽-Moment hat.

Natürlich hält sich nicht jeder an PEP8. Deine Auswahl an Projekten wo Du das beobachtest, führt IMHO aber auch zu einer Verzerrung, weil das zu einem signifikanten Teil Projekte sind, die nicht von Python-Programmierern geschrieben sind, sondern von C- oder C++-Programmierern (aus dem „embedded“/Mikrokontroller-Bereich) die mal eben schnell einen C oder C++ Code nach Python portieren, oder eine C-Bibliothek an Python anbinden, und dabei nur eine Untermenge der Sprache gelernt haben um den Code mehr oder weniger 1:1 zu übertragen.

Du sagst Du dachtest an einen Austausch, nimmst aber keine konstruktive Kritik an, sondern fasst offenbar jede Kritik an Deinem Code als persönliche Kritik an Dir auf. Und gehst auf die technischen Anmerkungen und Verbesserungen überhaupt nicht ein. Da kommt statt dessen „Oberlehrer“, „ich mag Dich nicht“, und alberne Vorwürfe ich würde Dich „stalken“, und ähnliches zurück. Du nimmst das alles viel zu persönlich, und unterstellst wahrscheinlich deswegen auch anderen Motive wie „im Stolz verletzt weil ein Newbie was geschafft hat ohne sich an Konventionen zu halten“, weil das ist wie Du das anscheinend siehst. Ich ganz sicher nicht. Ich halte mich an bestimmte Konventionen, weil ich das für sinnvoll halte. Auf so eine Selbstverständlichkeit bin ich nicht stolz, weil das keine besondere Leistung ist.

Datentypen werden nicht zugewiesen, beziehungsweise wenn dann nur indirekt. Namen haben in Python keine Typen, Werte haben Typen. Variablen haben in der Regel einen Namen, eine Adresse im Speicher, einen Typ, und einen Wert. In Python gehören die Adresse und der Typ fest zum Wert. In anderen Programmiersprachen, beispielsweise C gehört die (teilweise relative) Adresse und der Typ fest zum Namen.

Mit dem IBM PC und DOS haben sich nicht die schlechtesten Sitten verbreitet. Zum Beispiel was die Dateinamen angeht sind die Einschränkungen ja von CP/M übernommen. Und klar gab es Systeme wo längere Dateinamen möglich waren, aber es gab auch welche da waren die noch kürzer. Man hätte es also auch noch schlechter erwischen können. Ich fand die Einschränkung auf Länge und Inhalt, von Commodore 8-Bit-Rechnern kommend auch, nun ja einschränkend. Von 16 Zeichen in denen so gut wie alles vorkommen konnte, auf die 8+3-Zeichen von DOS. Aber auf der anderen Seite standen halt viele Vorteile und das Preis-Leistungsvehältnis von günstigen Klonen, Erweiterungen, und Software, zu dem Zeitpunkt wo ich mir dann einen PC zugelegt habe.

Moinsen,

betrachten wir mal den Fall ganz nüchtern.
Mir ist es egal was hier jeder denkt oder für Meinungen vertritt, denn dieses Forum soll gemäß der Eigendeklaration eine Hilfeforum für Problemlösungen um das RasPi und artverwandte Controller / Einplatinencomputer sein.

Hier macht sich unabhängig der Person jemand die Mühe aus dem Kreis der immer zunehmenden Inkompatibilität verschiedener Bibliotheken auf verschieden OS Versionen ( Buster bis Bookworm) und 32 bit oder 64 bit auf unterschiedlichen Hardware Plattformen eines einzigen Herstellers Raspberry Pi Foundation auszubrechen, und liefert hier einen funktionierenden Code ab, der unabhängig möglicher Hardware Konfigurationen und Zusatzbestückung funktioniert, weil auf die vollständige Nutzung von Hardware Implementierter Schnittstellen vollständig verzichtet wird.

Das erkennt keiner von euch an ! Keiner hat mit der angegebenen externen Hardware diesen Code auf Funktion verifiziert. Oder etwa doch ?

Jeder, und ich betone jeder hackt hier auf einem Menschen herum, der sein Tagwerk allen Mitgliedern auch späteren Lesern kostenfrei und funktionsgetestet zur Verfügung stellt.

Sieht man hier aus der Mitgliedergemeinschaft auch nur ein anerkennendes Wort für dieses Werk ? Nein

Vielleicht solltet ihr alle mal lernen auch diesen Gesichtspunkt zu überdenken ?
Und dann kann man das auch mit anderen Worten formulieren, wenn man Manöverkritik üben will, was bei einem Mitglied auffällig ist, und schon fast an einen BOT erinnert, dass unter jedem Pythoncode, der nicht einem einzigen Narrativ immer der gleiche fast im Serienbriefformat gesetzte Text gesetzt wird.

In erste Linie sollte dem TO soviel Respekt gezollt werden, das er hier überhaupt nach all den bisherigen Attacken überhaupt noch etwas veröffentlicht. Aber soweit scheint es bei einigen nicht mehr zu reichen, weil in dieser Ellenbogengesellschaft immer nur noch die eigene oder die Mehrheitsmeinung als die absolute Wahrheit angesehen wird. Das zeigt sich auch in der Kritik Formulierung. Und ich bleibe dabei, kein von euch, die sich hier alle aufregen und weiter auf dem TO herum hacken, hat sich mit dem Code dahingehend auseinander gesetzt, das er diesen Code unabhängig seines Typus ausprobiert hat.
Schämt euch !

Quote from Franky07

Das erkennt keiner von euch an !

Hast du #5 gelesen?

Quote from framp

Hast du #5 gelesen?

Mein Aussage bezog sich auf die Mitglieder die hier nur und ausschließlich Kritik an diesem Code üben, nur weil ihren der Typus nicht gefällt.

Batucada2
Ich finde das Thema eine interessante Sache, zumal ich im 3D Druck öfter mit EEPROMs zu tun hatte.
Was wäre denn da z.B. eine Anwendung für einen Pi oder Mikrocontroller, die normal mit SD Karten als EEPROM Ersatz arbeiten könnten ??

Bei meinem 3D Drucker werden/wurden gerätespezifische Parameter abgelegt, damit man diesen autark ohne Server betreiben konnte.
Da dieser nun über den Repetier Server gesteuert wird (über den Pi), ist aber auch das inzwischen überholt, da diese Parameter nun auf der SD Karte des Pi abgelegt werden.

Franky07 Ich habe das nicht mit der Hardware verifiziert weil ich die nicht habe. Aber ich sehe den Quelltext, ich sehe die Namen, und ich sehe die API und da gab es halt Verbesserungspotential. Das habe ich angesprochen und auch eine überarbeitete Version erstellt. Ich habe nicht auf einem Menschen herumgehackt, sondern Code qualitativ verbessert.

Was das anerkennen angeht: das ist teilweise KI-generierter Code der handwerklich nicht gut ist. Wie anerkennend muss man da bitte sein? Du kritisierst, dass den Code wahrscheinlich keiner verifiziert hat: hast Du Dir die Kritik mal inhaltlich angeschaut? Mal wenigstens überlegt wie Code aussehen müsste der zum Beispiel 10 Bytes ab Adresse 100 liest oder schreibt, mit der API der man nur Anerkennung zollen sollte wenn man die Hardware nicht hat, aber lesen und verstehen kann?

Meine konstruktive Kritik und Überarbeitung war auch kostenfrei und für alle zukünftigen Leser. Und was das ”Tagwerk” angeht, bin ich mir nicht so ganz sicher wie viel Arbeit da überhaupt reingesteckt wurde, und wie viel einfach KI-generiert ist ohne das selbst mal kritisch durchzulesen. Denn das wäre für mich zumindest eine plausible Erklärung warum ein nach eigener Aussage erfahrener Programmierer, der 20 Programmiersprachen beherrscht, so eine schlechte API abliefert.

Edit: Mir ist nicht ganz klar was mit „Typus“ in diesem Kontext gemeint ist‽