Ihr werde nur nicht viel damit anfangen können, die Ausgabe erfolgt über 4 doppelte Siebensegment Module.
Die Module haben je zwei gemeinsame Anoden (eine für die linke und eine für die rechte Stelle), die Segment-Kathoden sind alle zusammengeschlossen und gehen über Vorwiderstände direkt auf den µC.
Die gemeinsamen Anoden gehen direkt auf den µC.
Ja, das könnte man auch eleganter lösen aber darum geht es jetzt nicht, es geht mir nur um die modulo Sache in Zeile 429.
Ja, die Funktion "ReturnDigitFromNumber" ist noch nicht fertig, ich wollte erstmal nur die Einerstelle ausgeben, dann wenn das klappt auch noch die Zehnerstelle und so weiter.
Nein, das ist ganz und garnicht "wie gewünscht". Das ist erstens kein Minimalprogramm und zweitens...
Ihr werde nur nicht viel damit anfangen können, die Ausgabe erfolgt über
4 doppelte Siebensegment Module.
...auch nicht problemlos für jeden nachvollziehbar. Den Grund nennst du ja bereits selber: Es ist eine konkrete Hardware nötig, um das Problem überhaupt erkennen zu können. Was doch sehr stark dafür spricht, dass nicht die Modulofunktion an sich das Problem sein kann, sondern nur deine Verwendung selbiger im Kontext deiner Anwendung falsch ist.
Ich wollte mit dem modulo eine große Zahl in einzelne Ziffern aufteilen um diese einzeln auf den jeweiligen 7 Segmentanzeigen darstellen zu können.
Das Darstellen von einzelenn Ziffern (0 bis 9) funktioniert, aber wenn ich von einer größeren Zahl die Einerstelle "auslesen" will dann funktioniert das nicht.
Um die Einerstelle von z.B. 12345 zu bekommen kann man doch 12345%10 nehmen, oder?
Das würde 5 entsprechen richtig?
Modulo ist doch "der Rest der Division" (vereinfacht gesagt).
Ist mir auch gerade aufgefallen. Da sollte wohl ein > stehen.
Danke!
DANKE!!1
Das gerichtet und es läuft!
Also funktioniert % einwandfrei, nur der "Rest" drumherum.
Bei einem "Minimalbeispiel" wo das Ergebniss von der Modulo-Operation direkt z.B. über UART ausgegeben wird oder einfach direkt auf einen PORT wäre das nicht aufgefallen.
Eine Nacht drüber schlafen und DEN GANZEN CODE ansehen hätte in dem Fall geholfen.
Entschuldigung dass ich eure Zeit hier mit meiner Inkompetenz verschwendet habe.
Bei einem "Minimalbeispiel" wo das Ergebniss von der Modulo-Operation
direkt z.B. über UART ausgegeben wird oder einfach direkt auf einen PORT
wäre das nicht aufgefallen.
Man hätte festgestellt, dass das Ergbnis deiner Fehleranalyse falsch war.
Dann hätte man weiter suchen müssen.
Bei einem "Minimalbeispiel" wo das Ergebniss von der Modulo-Operation
direkt z.B. über UART ausgegeben wird oder einfach direkt auf einen PORT
wäre das nicht aufgefallen.
Das hätte immerhin gezeigt, dass Modulo funktioniert. Du also de facto den Fehler an der falschen Stelle suchst...
Entschuldigung dass ich eure Zeit hier mit meiner Inkompetenz
verschwendet habe.
Es gibt schlimmeres. Du hast immerhin erkannt, dass der Fehler bei dir lag (und mit Modulo rein garnix zu schaffen hatte).
Nicht jedem gelingt es, so mit eigenen Fehlern umzugehen. Insofern besteht zumindest Hoffnung...
Bravo.
Du hast erfolgreich widerstanden, eines der tausenden Beispiele im Web anzuschauen, wie andere eine 8-stellige Anzeige multiplexen. 500 Zeilen hat bestimmt keiner geschafft.
Das mit den Anoden direkt an den IO-Pins solltest Du nochmal überdenken.
Als Operating Conditionen werden für den ATmega8 max 20mA angegeben. Bei 7 Segmenten sind also max 2,8mA zulässig.
8 Digits multiplexen bedeutet, sie leuchten nur 12,5% der Zeit.
Das ergibt dann effektiv 0,35mA je LED, dürfte also recht dunkel sein.
Daß LEDs nie direkt an Ports gelegt werden dürfen, sondern immer einen Vorwiderstand zur Strombegrenzung benötigen, setze ich mal voraus.
Wahrscheinlich hat er sich gedacht: printf() braucht 1,5 kB Flash, das ist gar nicht gut. Und dann hat er 1,4 kB selbst programmiert, um das "Problem" zu umgehen.
Wahrscheinlich hat er sich gedacht: printf() braucht 1,5 kB Flash, das
ist gar nicht gut. Und dann hat er 1,4 kB selbst programmiert, um das
"Problem" zu umgehen.
Was soll ich darauf antworten? Ihr habt natürlich alle recht ...
Aber wie wärs zwischendurch mal mit "The Zen of Python" - eine Sammlung von 19 "Leitprinzipien" zum Schreiben von Computerprogrammen, nicht nur in Python? Der Software-Ingenieur Tim Peters formulierte diese Leitprinzipien und veröffentlichte sie 1999 auf der Python-Mailingliste.
Nicht, dass ich Python sonderlich mag, aber offensichtlich werden diese Prinzipien in manchen Kreisen also so wichtig angesehen, dass (moderne) Python-Interpreter auf
import this
antworten mit:
[...]
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
[...]
Die Soft-Serial Version (in HelloTiny) eignet sich auch gut für Fälle, wo die seriellen Ports des Mikrocontrollers schon alle belegt sind. Eine Ausgabe auf einem einzelnen freien I/O Pin lässt sich fast immer leicht hinzufügen.
Also die "große Zahl" in einen String umwandlen und dann einfach per index (ein String ist ja ein char array) oder Pointer auf die gewünschte Stelle zugreifen?
Clever!