mikrocontroller.net

Forum: Projekte & Code "Bessere" T6963c Library


Autor: Simon K. (simon) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hoi,

Vorab: Ich möchte jetzt hier keine vorhandene Bibliothek als schlecht 
bezeichnen, aber das, was ich hier (und bei avrfreaks) gefunden habe, 
hat mich nicht zufriedengestellt.
Mal wurde zum Beispiel beim String-write oder beim Bild-voll-schreiben 
kein AutoWrite des T6963c Modus benutzt, der das ganze um das doppelte 
beschleunigt. Dann waren nicht alle Funktionen eingebaut. Mal waren 
sogar Sachen fehlerhaft implementiert (Wobei ich bei mir auch nicht den 
Anspruch an komplett fehlerfreier Implementierung habe). Oder der Code 
einfach nur dermaßen schlecht strukturiert.

Ich hab daraufhin eine eigene Low-Level Bibliothek gebaut. Also ohne 
höherliegende Zeichenfunktionen (Rechtecke, Kreise...). Sondern nur die 
eingebauten Zeichenfunktionen (SetPixel zum Beispiel).

Noch ein paar Bemerkungen dazu:
main.c ist ein einfaches Sample, dass die Funktion der Library zeigt.
T6963c.c / T6963c.h sind die Library Dateien, wobei die Header-Datei per 
#include eingebunden und die .c Datei einzeln kompiliert wird.
Die Dateien "SamplePic.h" udn "CustomChars.h" gehören ebenfalls zum 
Sample und definieren ein (von mir geschossenes ;)) Beispiel-bild und 
ein Custom-Char.

Innerhalb der Lib sind die Basisfunktionen (Einfaches Byte-Schreiben und 
Byte-lesen) als Inline ausgeführt, was die Library relativ groß macht 
(Dadurch aber auch schneller). Wer das nicht möchte, weil er wenig Flash 
zur Verfügung hat, kann das Attribut, sowie das "static inline" bei den 
Funktionen entfernen.

Die Warteschleifen sind für 20MHz ausgelegt (Mega644) und durch 1-3 nops 
realisiert. Unter langsameren Prozessoren kann man diese teilweise, oder 
ganz 'rausschmeißen, wenn man noch etwas an Speed herausholen will. 
(_delay_us(.0XX) hat sich hier leider als schlecht erwiesen, weil dieser 
immer mindestens ein paar Taktzyklen für seinen eigenen Aufbau verheizt, 
sodass ich quasi viel zu lange warte).

Die Pinbelegung kann in der Header Datei angepasst werden, wobei aber 
Alle DatenPins an einem Port liegen müssen, sowie alle Controlports an 
einem Port.

Die Adressen des T6963c Speichermappings können ebenfalls angegeben 
werden. (CGRAM-Adresse lässt sich nicht komplett frei verschieben!).

Manche "Funktionen" sind noch als Makro ausgeführt, da diese nur eine 
Kombination aus 2 vorhandenen "echten" Funktionen darstellen.

Im Ordner "CharGen" habe ich eine einfache Exceltabelle beigelegt, womit 
man sich Zeichen zusammenklicken kann.

Um Grafiken wie das Beispiel-Bild in C umzuwandeln, kann man das Tool 
"bmp2c" von Holger Klabunde benutzen. Klappt sehr gut (google!)

Dann mal Viel Spaß damit, und nicht das Feedback vergessen ;) ;)

PS: Bei mir läuft die Library mit einem 240x128 T6963c an einem Mega644 
mit 20MHz Takt. Sollte aber ohne Probleme auch mit anderen 
Größen/Mikrocontrollern funktionieren.

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmmmm, memory mapped für einen Mega162 oder größer hast Du nicht auch 
zufällig?
Das bräuchte ich nämlich...

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nope, memory mapped habe ich nichts da. Finde ich eher umständlich, da 
man noch diverse Dekodierer braucht um über die Adressen die 
Schreib/Lese/CodeData Pins anzusteuern. Und sooo viel schneller wirds 
dadurch nicht. (Ich bin ja mit 20MHz schon schneller als der T6963c). 
Der einzige Vorteil wäre nur, dass der Mikrocontroller sich im 
Hintergrund um das Ausgeben des Bytes kümmert.

Naja, muss man jetzt abwägen ;)

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab das ganze jetzt auch mit Bildern auf meiner Homepage:
http://klinkerstein.m-faq.de/index.php?content=T69...

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab noch ein paar nebensächliche Sachen ausgemerzt, und außerdem ein 
#define für's Inlining der Core-Funktionen eingefügt (T6963c.c).
Die aktuellste Version gibts immer auf meiner Homepage.
Bei avrfreaks zeigt ein Projekt immer auf meinen Webspace:
http://www.avrfreaks.net/index.php?module=Freaks%2...
Der link direkt zu meinem Webspace (Wo auch Bilder zu finden sind) ist:
http://klinkerstein.m-faq.de/index.php?content=T69...


Wenn fragen sind, so schreibe man mir einfach eine E-Mail ;)

PS: Ich reichte eventuell demnächst Grafikfunktionen nach.

Autor: Thomas G. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Entschuldigt mich wenn ich störe, aber ich verwende zurzeit ein DMF5001 
Optrex Panel, welches den Pin HALT scheinbar vom T6963c Kontrollerchip 
nach aussen geführt hat. Dieses Panel bekomme ich einfach nicht zu 
laufen. Aus anderen Berichten entnahm ich, das dieser Pin dauerhaft auf 
einen High-Pegel zu setzen ist. Dies würde aber laut T6963C Spec doch 
eher unwahrscheinlich sein. Ich wollte daher fragen, wie dieser Pin im 
Code zu verwalten wäre. Das Display hat ausserdem eine 160x128 
Auflösung, welche nicht gerade dem "Standard" (128x64, 240x128 usw.) 
entspricht.
Die Versorgung des Panel ist in Ordnung und überprüft, blos bekomme ich 
selbst mit dem HALT Pin auf High-Pegel gesetzt nicht einen anständigen 
Wert (egal ob Bild oder Text) angezeigt. Ich hoffe, dass ich euch mit 
diesen Fragen nicht allzu belaste, wäre aber um Lösungsvorschläge jedoch 
sehr dankbar. Hatte leider selbst mit anderen T6963c Libs keine 
Besserung des Zustandes. Zurzeit verwende ich einen ATMega16 mit 
internem 8Mhz Takt.

Autor: Markus B. (wolframator)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich versuche gerade eine kleine Grafik von 32*32 Pixel und Small-Font 
"mitten ins Display" zu stellen.

Dabei ergibt sich das Bild im Anhang. Was rot eingekreist ist ist ok und 
gewollt, ansonsten sollte nur eine art Sonne zu sehen sein wie links 
oben mit ins Bild kopiert wurde.

Der Code hierfür ist (die in dem Thread genutzte Bibliothek benutzund 
der hier:
const uint8_t g_Sonne[] = { 0x00,0x00,0x02,0x00,0x00,0x00,0x00,0x00,0x02,0x00,0x00,0x00,0x00,0x08,0x07,0x00,0x20,0x00,0x00,0x0C,0x07,0x01,0x20,0x00,0x00,0x06,0x07,0x03,0x00,0x00,0x00,0x07,0x07,0x07,0x00,0x00,0x00,0x07,0x2F,0x2F,0x00,0x00,0x00,0x07,0x3F,0x3F,0x00,0x00,0x0C,0x03,0x3F,0x3E,0x01,0x20,0x07,0x33,0x3F,0x3E,0x1F,0x00,0x03,0x3F,0x3F,0x3F,0x3E,0x00,0x01,0x3F,0x3F,0x3F,0x3C,0x00,0x00,0x3F,0x3F,0x3F,0x38,0x00,0x00,0x1F,0x3F,0x3F,0x30,0x00,0x00,0x3F,0x3F,0x3F,0x38,0x00,0x0F,0x3F,0x3F,0x3F,0x3F,0x20,0x3F,0x3F,0x3F,0x3F,0x3F,0x30,0x0F,0x3F,0x3F,0x3F,0x3F,0x20,0x00,0x3F,0x3F,0x3F,0x38,0x00,0x00,0x1F,0x3F,0x3F,0x30,0x00,0x00,0x3F,0x3F,0x3F,0x38,0x00,0x01,0x3F,0x3F,0x3F,0x3C,0x00,0x03,0x3F,0x3F,0x3F,0x3E,0x00,0x07,0x33,0x3F,0x3E,0x1F,0x00,0x0C,0x03,0x3F,0x3E,0x01,0x20,0x00,0x07,0x3F,0x3F,0x00,0x00,0x00,0x07,0x2F,0x2F,0x00,0x00,0x00,0x07,0x07,0x07,0x00,0x00,0x00,0x06,0x07,0x03,0x00,0x00,0x00,0x0C,0x07,0x01,0x20,0x00,0x00,0x08,0x07,0x00,0x20,0x00,0x00,0x00,0x02,0x00,0x00,0x00 };

uint8_t i;
uint8_t j;

for(j=0; j<32; j++)
{
  for(i=0; i<6; i++)
  {
    T6963cWriteChunkAt_P(T6963C_ADDR_GRAPHIC+10+(40*j)+i, &g_Sonne[(j*6)+i], 1);
  }
}

Irgendwas muss ich doch falsch machen wenn da sowas komisches bei raus 
kommt.

Autor: Jim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann viele Ursachen haben.
Gib mal mehr Details.
Welche Auflösung, was für ein Display, welche Zeichensatzgröße?
Insbesondere, wenn die Displayroutinen nicht auf jede mögliche 
Zeichensatzgröße (5x8, 6x8, 7x8, 8x8) ausgelegt sind, kommen solche 
Artefakte zustande.

Autor: Markus B. (wolframator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
- 240x64 Pixel Display
- 6x8 Small Font (auch passend deklariert)
- Bilder (fullscreen) sind fehlerfrei

Autor: Markus B. (wolframator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da die Editierfunktion leider nicht ging...

Hab die Grafik mit dem FastLCD gemacht und passend exportiert. Leider 
scheint das Programm die Pixel falsch zu berechnen. Mit dem BMP2C vom 
Klabunde ging es jetzt :) Interessanterweise ist jetzt auch der 
Datenmüll im unteren Bild weg :D

Autor: Paul W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
Die Lib funktioniert bei mir leider nicht richtig, aber ich nehme an, 
dass der Fehler einen halben Meter vor dem Monitor sitzt. Zwar wird das 
LCD richtig initialisert und es kann auch Text dargestellt werden, aber 
der Text wird nicht klar dargestellt. Der Text wird praktisch zwei mal 
dargestellt, einmal "stark" und einmal in x-Richtung versetzt "schwach". 
Sobald ich den Stecker ziehe und dem ganzen den Strom wegnehme, wird der 
Text kurzzeitig so dargestellt, wie er sein sollte.

Hier kurz die wichtigsten Codes:
int main(void)
{

  //Initialize
  //OR mode, internal CG, Text and Graphic, Blinking Cursor
  T6963cInit(  T6963C_MODE_OR | T6963C_CG_INTERNALROM,
        T6963C_TEXT_GRAPHIC | T6963C_CURSOR_BLINK );
  
  T6963cPutStringXY(0, 0, "Dies ist eine doch sehr lange Reihe ");
  T6963cPutStringXY(1, 1, "Dies ist eine doch sehr lange Reihe ");
  T6963cPutStringXY(2, 2, "Dies ist eine doch sehr lange Reihe ");
  T6963cPutStringXY(3, 3, "Dies ist eine doch sehr lange Reihe ");
  T6963cPutStringXY(4, 4, "Dies ist eine doch sehr lange Reihe ");
  T6963cPutStringXY(5, 5, "Dies ist eine doch sehr lange Reihe ");
  T6963cPutStringXY(6, 6, "Dies ist eine doch sehr lange Reihe ");
  T6963cPutStringXY(7, 7, "Dies ist eine doch sehr lange Reihe ");


   while(1)
  {
    ;  
  }

  return 0;
}


mit
//Physical Description
#define T6963C_ADDR_CGRAML        0x1800  //Lower half of CG (Chars 00-7F)
#define T6963C_ADDR_CGRAMH        T6963C_ADDR_CGRAML + 0x80*8  //Higher half of CG (Chars 80-FF)
#define T6963C_ADDR_GRAPHIC        0x0400
#define T6963C_ADDR_TEXT        0x0000
#define T6963C_TEXT_COLS        40    //40 bytes for 6x8 Font, 30 for 8x8 Font
#define T6963C_TEXT_ROWS        8
#define T6963C_GRPH_COLS        T6963C_TEXT_COLS
#define T6963C_GRPH_ROWS        64
#define T6963C_FONTWIDTH        6

in der .h-Datei.

Verwendet wird ein Atmega32 und ein GLCD mit 240x64 Pixeln.
Mir ist klar, dass ich die 8 Funktionenaufrufe "geschickter" machen 
könnte, aber ich war irgendwie zu faul und C&P schien mir einfacher :D.
Morgen wird ein Bild hinzugefügt. Zur Zeit sieht es wegen den 
Lichtverhältnissen nicht sehr gut aus für ein Bild :-).

BTW: Wieso wird _GRAPH_COLS gleich _TEXT_COLS gesetzt?? Versteh ich 
ehrlich gesagt nicht, aber auch wenn ich _GRAPH_COLS auf 240 setze 
bessert sich nichts.

Vielen Dank!

Autor: Clyde H. (clyde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich glaube, ich brauche Hilfe...
Ich nutze die Libary mit einem Mega( und einem LMG7420 mit T6963.
Ich habe es soweit, das ich Text da hinbekomme, wo er hin soll.
Leider ist der Grafikbereich um ca. 1/4 nach Links verschoben(der 
Katzenkopf(im Original) ist einmal Links und dann wieder rechts im 
Display.
Beim 8x8 Modus klappte das, aber wenn ich das Display auf 6x8 stelle, 
dann stehe ich vor diesem Problem.
Nebenbei wird mein eigener Character(vorher der "play-pfeil" halbiert, 
die linke hälfte fehlt dann)

Eine veränderung von
#define T6963C_GRPH_COLS        30
nach
#define T6963C_GRPH_COLS        40

hat nur wenig bewirkt, aber immerhin ist die Linie unten rechts im 
Display weg(die ist von meinem Rahmen den ich selbst gezeichnet habe).
Scheinbar gibt es da ein Problem mit em Speicherzeiger o.ä. Hat da 
jemand ein ähnliches Problem und eine Lösung parat?

Gruß
Clyde

Autor: Hannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Clyde H. (clyde):

Ich hatte das gleiche Problem. Manche Displays können den 6x8 Modus 
schlicht nicht, weil die intern entsprechend verdrahtet sind.

Dazu gab's auch schon mal einen Beitrag:

Beitrag "Re: Display mit T963C"

Autor: Clyde H. (clyde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Morgen und danke für den Link.
Leider half mir das nicht so ganz...
Der Textmodus klappt bei mir einwandfrei, auch der Zeilenumbruch bei 
mehr als 40 Zeichen funktioniert ohne Pixelversatz.
Nur der Grafikmodus ist versetzt, so wie in Deinem verlinkten Thread 
beschrieben. Habe ich was überlesen oder hängt es doch noch wo anders...
Werde heute Abend mal die MD-Pins kontrollieren und gucken, wie die 
belegt sind.

Gruß
Clyde

Autor: Clyde H. (clyde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe mal geguckt, aber noch nicht gemessen...
MD0 und 1 liegen auf Masse MD2 ebenfalls und MD3 scheint NC oder 
woanders angeschlossen zu sein(MD3 auf GND schliesse ich aus, weil dem 
Layout nach ein direkter kontakt möglich wäre.FS0 ist auch GND.

Falls wichtig, es ist ein 4,91Mhz Quarz installiert sowie 2x LC7942 und 
3x LC7940
evtl. hilft es.

Gruß
Clyde

Autor: Clyde H. (clyde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo wieder,
zur Info in eigener Sache...
Den Grafikbereich habe ich immer noch nicht in Griff...

Aber, das mit den eigenen Zeichen(CharGen) war mein Denkfehler,
da im 6x8 Modus ja die ersten 2 Bits ignoriert werden und ich mein 
"Grad" Zeichen ganz links gesetzt habe, wurde die hälfte abgeschnitten
(habe ja nur 4 Pixel in die Breite gezeichnet).

Wenn ich eine Linie von 0-240(ich weiß, wären eigentlich 241 Pixel aber 
bei 239 ändert sich auch nix bewegendes am Grundproblem) zeichen lasse, 
dann sind die letzten 60 Pixel im Display leer.
Wenn ich von 0-19 zeichnen lasse, fehlen rechts 7 Pixel...

Irgendwie komisch, oder?

Wer hat ähnliche Probleme?

Gruß
Clyde

Autor: Paul W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich will die Library keineswegs schlecht reden, aber mir hat es ungemein 
geholfen, als ich mich selbst mit den Routinen und dem Datenblatt vom 
Controller (T6963C) beschäftigt habe.

Wie hast die die Home-Adresse vom Grafik und Text-Bereich definiert?

Autor: Clyde H. (clyde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe nichts weiter am Originalcode geändert ausser die Ports zur 
Ansteuerung, da ich ja nen Mega8 nutze und keinen 32er.
Ich versuche mich auch da durch zu wuseln, aber die Operatoren und 
Bitverschiebungen sind mir noch ziemlich bömisch...

Gruß
Clyde

Autor: Clyde H. (clyde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Morgen,

es war mein Fehler Schande...
Ich habe die Version hier im Thread genommen, mit der Version von 
Simon´s HP klappt es!

Gruß
Clyde

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Clyde H. wrote:
> Guten Morgen,
>
> es war mein Fehler Schande...
> Ich habe die Version hier im Thread genommen, mit der Version von
> Simon´s HP klappt es!

Gut zu wissen :-) Hab nur ratlos zuschauen müssen. Schade, dass ich in 
den ersten Beitrag keinen Link mehr zu meiner Seite hinzufügen kann.

Wie auch immer: http://de.klinkerstein.m-faq.de/index.php/T6963c_Library

Autor: Clyde H. (clyde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. wrote:
> Gut zu wissen :-)

Das sagste wohl, vor allem weil ich immerwieder mal gucke, auch wegen 
dem uWebServer :-)
Manchmal ist man sich selbst im weg, aber somit wird es für andere evtl. 
direkt ersichtlich:-D

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Ich habe das Programm erfolgreich zum laufen gebracht. Nun möchte ich 
mehrere Bilder nacheinander anzeigen lassen. Das funzt auch soweit, nur 
muss ich dazu die #define T6963C_GRPH_COLS immer denm jeweilligem Bild 
anpassen. Nun wollte  ich die T6963C_GRPH_COLS als Variable definieren, 
habe dazu in der T6963c.h extern uint8_t T6963C_GRPH_COLS eingebunden 
und inder main.c sie als Global initialisiert. Wenn ich hier den Wert 
gleich zuweise, funzt es. Wenn ich in der main, kurz bevor ich das Bild 
aufrufe, den Wert zuweise gehts nicht. Als wenn er die Variable in der 
main nich mehr kennt????

Gruss
Frank

Autor: Stefan S. (stsc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

gäbe es eine Möglichkeit die Anzahl der verwendete PINS zu reduzieren. 
Momentan werden 13 für den T6963C benötigt. Wie könne man das 
reduzieren.
Evtl. könnte man so ein Display auch per I2C ansteuern, aber ich denke 
dafür ist der I2C Bus zu langsam.

Gruss,
Stefan

Autor: Fabian B. (fabs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du könntest alle Pins über Schiebregister ansteuern, das ginge dann mit 
3 Pins für's Display. Macht die Sache aber nicht unwentlich langsamer.

Gruß
Fabian

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, langsam oder "zu langsam" ist ja immer relativ. Wie schnell muss 
das Display denn geupdatet werden? Für 1 mal pro Sekunde reicht sowas 
dicke.

Autor: Pete K. (pete77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe so ein Display an I2C angeschlossen. Bei 400kHz ist es doch 
sehr zäh, Textdarstellung ist ok. Mehr als 600kHz macht leider meine RTC 
nicht mit, liegt aber ja auch außerhalb der Spezifikation.

Autor: Fabian B. (fabs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Interessanter wäre darum die Pins des Displays an z.B. 595er 
Schieberegister zu hängen. Die kannste mit bis zu 20MHz befeuern. Da 
dürfte eher wieder das Display die Bremse werden.
Die 20MHz schafft man natürlich mit nem AVR nimmer...

Gruß
Fabian

Autor: Paulemeister (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,
Versuche gerade die aktuellste Version der lib für ein 128x64 Display 
und Grafikausgabe umzubiegen. Ich scheine aber an der falschen Stelle 
anzusetzen.
Die per BMP2C konvertierten Bilder werden falsch und auch nur bis zur 
vertikalen Hälfte angezeigt.

Welche Werte in der t6963c.h müssen denn nun angepasst werden ?
Mein Ansatz war
T6963C_GRPH_ROWS 64
T6963C_TEXT_ROWS  8
alles Andere habe ich so belassen wie es ist. FS ist auf LOW für 8x8.
Funktioniert aber nicht. Hat irgendjemand da einen kleinen "Anstoss" ;) 
?

Autor: Clyde H. (clyde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

hat schon jemand versucht, mit dieser LIB größere Fonts zu erstellen?
Ich habe bei anderen Libs(Niko Sachs) davon gelesen aber nutze die von 
Simon K.(und bin damit zufrieden und komme gut klar)
Nun wüsste ich gerne, wo ich ansetzen müsste bei der Lib um die 
entsprechenden Zusatzprogramme für Simon K´s Lib nutzen zu können für 
größere Fonts.

Vielen Dank.
Gruß
Clyde

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Da es prog_char und prog_uint8_t mittlerweile nicht mehr gibt (weil
die Annahme, dass ein typedef auch ein attribute((progmem)) mit
aufnehmen könnte, sich als irrig herausgestellt hat), habe ich das
mal geändert.  Habe selbst aber kein T6963c, um es zu probieren.

Autor: Philipp Kuh (schuppeste)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

mir ist aufgefallen das DATA aus einem Port genutzt wird, wie kann ich 
Data auf Diverse Pins aus verschiedenen Ports zuweisen ?

Gruß,
Schuppeste

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.