Bascom Dataports für GLCD

Fetti

Neues Mitglied
27 Okt 2014
4
0
0
Sprachen
Hallo,
ist es möglich, die Ports individuell zu belegen, oder ist man strikt an einen Port-Block gebunden?
Danke und Grüße
F

es geht um Bascom...
 

Fetti

Neues Mitglied
27 Okt 2014
4
0
0
Sprachen
Nun habe ich gelesen, dass man sehrwohl einen zusammenhängenden Port braucht, was bei mir auch der Fall ist, nur sind die Ports invertiert. Könnte man eine Anweisung a lá 255-x in die lib schreiben und wenn ja, wohin?
 

TommyB

Team Bitschubse
Premium Benutzer
17 Mai 2010
2.151
80
48
36
127.0.0.1 ;)
Sprachen
C#, VB.Net, LunaAVR, Assembler, Python
Ein zusammenhängender Port ist bei Bussystemen immer sinnvoll, da es dem Controller Zeit spart und diese Bitschubserei möglicherweise zu Timingproblemen führt.

Trotzdem. Schau mal bei Conrad, Pollin, Reichelt, RS, ... nach. Dann wirst du feststellen dass es mehr als nur ein GLCD gibt ;)
Vor allem Farbe / "schwarz weiß" gibt es gravierende Unterschiede.

Also bitte ein bisschen mehr Informationen :)
 

Fetti

Neues Mitglied
27 Okt 2014
4
0
0
Sprachen
Hi,
sinnvoll natürlich. Ich habe nur leider das PCB falsch angelegt, mit invertierten Anschlüssen zu einem KS0108. Mittlerweile habe ich alles überkreuzt, womit das Problem erstmal gelöst wäre:rolleyes:
Dennoch wäre es interessant zu wissen, ob man generell eine derartige Invertierung realisieren könnte, um mehr Freiheiten beim Platinenlayout zu haben.
Gruß
Christian
 

TommyB

Team Bitschubse
Premium Benutzer
17 Mai 2010
2.151
80
48
36
127.0.0.1 ;)
Sprachen
C#, VB.Net, LunaAVR, Assembler, Python
Du meinst also Bit 0 zu Bit 7, Bit 1 zu Bit 6, ... ?

Ohne Rechnerei wird da leider nix draus werden. Dann müsstest du die Lib ändern, auf die (jetzt längeren Timings achten), ...

Vorsicht: Python Code (nutz ich so auf dem RasPi)
Code:
def ReverseBits(byte):

    byte = ((byte & 0xF0) >> 4) | ((byte & 0x0F) << 4)
    byte = ((byte & 0xCC) >> 2) | ((byte & 0x33) << 2)
    byte = ((byte & 0xAA) >> 1) | ((byte & 0x55) << 1)
    return byte

#end def
Grade die Schubserei kostet Zeit. Gibt für C, Bascom, ASM bestimmt noch andere Lösungen.
Ist Zeittechnisch aber schon ungefähr das Selbe wie würde jeder Pin frei belegbar sein (und gesetzt werden)
 

LotadaC

Sehr aktives Mitglied
22 Jan 2009
3.401
62
48
Marwitz
Sprachen
BascomAVR, Assembler
Die Reihenfolge der Bits in einem Byte umkehren?
...Gibt für [...] ASM bestimmt noch andere Lösungen...
Das sind bereits 14 Schiebeoperationen und 9 logische Verknüpfungen.
Wenn man von einem Register in ein anderes schiebt, käme man mit 8mal schieben und rollen aus, also 16 Instruktionen (Takten)...
Bestimmt gibts noch was mit SWAPpen, aber dazu ist der Abend zu weit;)

Edit: hast Du ja quasi da zu stehen, die Zeile mit 0x0F und 0xF0 könnte durch das SWAP (eine Instruktion, ein Takt, ein Word im Flash) ersetzt werden...
ABER ich bin mir da nicht sicher, ob die "byte=bla or blub" nicht noch ein paar Kopierinstruktionen enthält. Bla und Blub benötigen ja beide das Originalbyte VOR dem OR und dem schieben

Edit2: gerade und ungerade Bits tauschen, wie bei Dir also die ungeraden Bits maskieren (byte ANDI 0xAA), rechtsschieben, die geraden Bits maskieren (byte2 ANDI 0x55) linksschieben und beide verORren. Byte2 muß aus Byte kopiert werden, bevor dieses maskiert und geschoben wird. Ich zähle 6 Eintakt-Instruktionen.
Bei den Pärchen (mit 0x33 und 0xCC) dasselbe, nur daß je zweimal geschoben wird - 8 weitere Instruktionen.
Die Nibbels (0xF0 und 0x0F) schlügen dann wegen der je 4 shifts mit 12 Instruktionen zu Buche. Wenn man das durch die Ein-Takt-Instruktion SWAP ersetzt, bliebe man mit 15 Instruktionen/Takten tatsächlich einen Takt schneller als beim Schieben/Rollen...

(@Thomas: wieweit die Himbeere da den Code optimiert, und ob die sowas wie SWAP kennt, weiß ich(!) natürlich nicht, aber im AVR würde der Nibbeltausch mit SWAP die Takte nahezu halbieren)
Hab ich mich vertan, Dino?

Und noch'n Edit: wenn's von der Zeit her nur schnell sein soll, und SRAM/FLASH/EEPROM-Verbrauch keine Rolle spielt, könnte man die Bytes auch in umgekehrter Reihenfolge irgendwo als Tabelle ablegen (also 0b11111111, 0b11111110, 0b11111101, ..., 0b00000001, 0b00000000) und dann einfach das zu invertierende Byte mit "irgendwo" addiert als Adresse auf einen Tabelleneintrag nutzen, und das Byte von da laden. Sollte zumindest im FLASH (mit LPM) und im SRAM (LD) unschlagbar schnell sein - kostet dort allerdings auch 256 Bytes Speicher...
 

TommyB

Team Bitschubse
Premium Benutzer
17 Mai 2010
2.151
80
48
36
127.0.0.1 ;)
Sprachen
C#, VB.Net, LunaAVR, Assembler, Python
@LotadaC:
Wenn man dir genug Zeit gibt bekommste das bestimmt auch in 4-5 Taktzyklen hin :D

Zum Swap: Die erste Zeile von dem Python Source macht ja eigentlich genau das. Hm...
Ich weiß jetzt auch nicht wie die Bascom Libs aufgebaut sind, aber ich meine in ASM, oder? (oder zumindest so eine Eigenbrötchen-Zwischenstufe)
 

LotadaC

Sehr aktives Mitglied
22 Jan 2009
3.401
62
48
Marwitz
Sprachen
BascomAVR, Assembler
...Zum Swap: Die erste Zeile von dem Python Source macht ja eigentlich genau das. Hm...
Ja, letzendlich ja, aber ob das so wirklich zu Fuß mit 12 Instruktionen/Takten umgesetzt wird (Byte kopieren, erste Kopie mit Maske verANDen, 4mal schieben, zweite Kopie mit Maske verANDen, 4mal schieben, beide verORren), oder ob das zu einem ein-Takt-SWAP optimiert wird, weiß ich nicht.
Bei Bascom (und wahrscheinlich auch bei C) bezweifel ich das (auch wenn Cassio und Hemi jetzt vielleicht auf die Barrikaden gehen - die wissen da eh mehr als ich).
Dann wäre Schieben und Rollen (16 Takte) schneller. Nutzt Du für den Nibbletausch SWAP, ist Dein Weg schneller. Divide&Conquer...
Der Weg über die Tabelle ist trotzdem irgendwann der schnellste - allerdings erfordert er Platz für die (vorher erzeugte) Tabelle (nur der Zugriff auf den Wert in einer Tabelle, also ein Zugriff und vorher die Addition der Adresse(Wert) mit der Startadresse)...
 

Fetti

Neues Mitglied
27 Okt 2014
4
0
0
Sprachen
Danke Euch. Der Tabellenweg kommt mir noch am praktikabelsten vor. Noch einfacher wird es aber dann wohl, beim layouten entsprechend zu planen und sich die Programmierarbeit zu sparen.:D
 

TommyB

Team Bitschubse
Premium Benutzer
17 Mai 2010
2.151
80
48
36
127.0.0.1 ;)
Sprachen
C#, VB.Net, LunaAVR, Assembler, Python
@Lotadac:
Das ist ja das generelle Problem bei nicht-ASM-Sprachen. Man weiß nie was der Compiler (oder Interpreter) daraus macht. Aber ich wage es mal zu bezweifeln dass es zu einem SWAP Befehl hin optimiert wird. Ich schätze mal dass da keine Optimierung greift und so drauf los gerechnet wird. War in meinem Fall auch kein Problem. Im Gegenteil, weil ASM auf ARM ist irgendwie ganz anders als ASM auf AVR ;)

Generell. Die Idee mit der Tabelle war gut, ist ein schöner Workaround wenn der Speicher vorhanden ist.
Aber am besten ist es eh immer: Erst Breadboard, dann Eagle :)

Warum sprecht ihr eigentlich von inventieren? Das ist doch eigentlich was ganz anderes als MSB first und LSB first zu tauschen.
 

dino03

Aktives Mitglied
27 Okt 2008
6.727
16
38
Sprachen
BascomAVR, Assembler
Hi,

ich hab mir das nun nicht alles durchgelesen. Ist schon etwas später und irgendwie hab ich mir ne leichte Erkältung eingefangen (Sch.. naß-windog-kaltes Wetter)

Noch einfacher wird es aber dann wohl, beim layouten entsprechend zu planen und sich die Programmierarbeit zu sparen.:D
genau aus dem Grund sollte man sich vorher überlegen was man für einen Mikrocontroller benötigt, wie man am besten die Pheripherie an den Pins verteilt und was man über Softwarebibliotheken oder über die eingebauten Hardwarefunktionen macht.

Gruß
Dino
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)