Deine for Schleife bestimmt, in welcher Reihenfolge die Bits gezählt werden. Ich bezweifle allerdings, dass deine 64 Bit Variable 88 Bits enthalten kann.
Ich bräuchte mal Hilfe mit einem Code für die Ansteuerung.
Ich habe 11 Stück 74HC595, die jeweils 84 LEDs ansteuern, 4 Ausgänge
sind leer, die Ansteuerung erfolgt scheinbar mit LSB und nicht mit MSB.
Wenn mein Task startet, gehen die LEDs in umgekehrter Reinfolge an und
wieder aus, also Beginnend bei Ausgang 88 bis Ausgang 73...
Wie drehe ich das um, so das Ausgang 1 - 16 angesteuert wird?
currentVal & (1 >> i)) brachte leider kein erfolg.
Logisch, du hast den Code nicht verstanden. Siehe Bitmanipulation.
Naja. Solche Sachen packt man in ein Array mit uint8_t Datentyp, das ist verdaulicher, auch für fette 32 Bit CPUs. Und viel besser erweiterbar auf beliebige Schieberegisterlängen.
Im aktuellen Code und auch meiner Version unten, liegt das Ende der LED-Kette am Anfang der Daten, denn die werden zuerst ausgegeben. Kann man ggf. auch umdrehen.
vielen Dank, habe den Code mal getestet, funktioniert.
Jetzt müsste ich nur noch das ganze gedreht bekommen, denn wenn ich Pin
1 auf 1 stelle, geht die LED 88 an u.s.w.
Tja, sagte ich ja bereits.
Über die Bitmanipulation müsste ich doch eigentlich das gedreht
bekommen?
Jain, man muss die Adressierung der Bytes auch spiegeln.
Wenn ich meine for-schleife nun aufif(data & (1>> j))
funktionierts leider nicht,
Logisch.
eigentlich muss ich doch die 1 in die andere
Richtung schieben mit 1>>j... ?
Wenn ich meine for-schleife nun auf
if(data & (1>> j))
funktionierts leider nicht
Versuche morgen nochmal, die Frage neu zu formulieren, so dass sie verständlich ist. Bei der Gelegenheit kannst du dann auch eine Skizze von der Verschaltung der Schieberegister und deinen LEDs mit Nummern nachreichen.
Für die 74HC595 kann man eine SPI-Schnittstelle nehmen, um bequem die Daten in die kaskadierten Chips hineinpumpen zu lassen, aber wenn man das Bitkippen schon selbst per Software macht oder üben will oder von mir aus auch machen muss und sowieso viele Kilobytes an SRAM noch übrig hat, kann man z.B. 100 Bytes für ein Bytearray opfern und jeweils nur ein Bit in einem Byte speichern, gerne auch an der LSB-Stelle, also im Bit 0. Dieser verschwenderische Umgang mit dem SRAM, der am Ende des Projekts sowieso ungenutzt im µController liegen würde, erleichtert unheimlich die Bitadressierung, also eigentlich dann schon die LED-Adressierung, da die LED-Adresse dann dem Index vom Array entspricht – demnach wird also auch das Codeschreiben sehr vereinfacht, obendrein wird im Hintergrund von der CPU vermutlich alles deutlich schneller ausgeführt, da grundsätzlich nur noch mit Bytes hantiert wird.
Man muss halt wissen, wann Sparen angesagt ist und wann aus Komfort- oder Geschwindigkeitsgründen das genaue Gegenteil angewandt werden darf – bei einem AT89C2051 oder AT89C51 kommt es auf jedes Byte an und dort muss man teilweise extrem sparen und oft auch zu Assembler greifen, weil auch der Flash relativ kurz ist, beim STM32 ist es Unsinn, krampfhaft irgendwelche Bitakrobatik mit Schiebe-, Modulooperationen oder gar Divisionen, die quasi mit jedem Schleifendurchlauf ausgeführt werden müssen, zu vollführen, wenn man sowieso sehr viel Speicher zur Verfügung hat und alles viel einfacher und vermutlich auch übersichtlicher oder leserlicher in C gestaltet werden kann. Wie ich bereits woanders mal sagte – eine kostbare Ressource, mit der schonend umgegangen werden muss, kann immer etwas anderes bedeuten, mal ist es der Speicher, mal die Zeit, ein anderes mal etwas ganz anderes oder eine Kombination aus allem, aber die wichtigste Ressource eines Homo sapiens ist die entsprechend gefaltete und vernetzte Hirnmasse, die es einem ermöglichen kann, über den Tellerrand hinauszuschauen und generell einen besseren Überblick zu bekommen; ja, zu bekommen, denn dieser wird nicht jedem von der geistigen, unsichtbaren Welt gewährt, geschenkt oder erlaubt, sich diesen selbst hart erarbeiten zu dürfen.
