Labels oder so was ähnliches

Wenn nur eine andere Zeichencodierung als ASCII verwendet wird, dann
mach's so:

Arbeite mit ASCII und konvertiere erst unmittelbar vor der Ausgabe mit
einer 256 Byte großen Tabelle. Der Index der Tabelle ist ASCII, der
Inhalt die Nicht-ASCII-Codierung.

Allerdings bin ich mir nicht ganz sicher, Deine Frage wirklich richtig
verstanden zu haben, der Teil mit den Labels beispielsweise erschließt
sich mir nicht.

Wird denn Dein VFD nun mit 44780 angesteuert? Woher stammt die
Information, daß eine andere Zeichencodierung verwendet wird?
Datenblatt des Displays?

Es werden nicht nur ASCII zeichen verwendet, auch Symbole wie Note oder
Pfeil.

Das Display wird nicht über 44780 angesteuert, die Berehle sind jedoch
die gleichen.

Ich habe meine Informationen aus dem Datenblatt. Es ist ein VFD vom
Typ: CU40025SCPB-W6J.

Als Anhang das Datenblatt(falls dies illegal ist bitte sagt es mir:D)

.equ _A = 0xFF

; verwendung dann zb.
 LDI r16,_A

; im neuen ASM2 (ab AVRStudio 4.11) geht auch


#define _B $EE
 LDI r16,_B

Danke,

Damit kann ich was anfangen.

Wenn ich mir die Tabelle auf Seite 13 des Datenblatts ansehe, dann kann
ich das Problem nicht nachvollziehen.

Das ist ASCII mit zwei kleinen Ausnahmen, Yen statt | und ein Pfeil
statt der Tilde ~.

Nur für die Darstellung von Umlauten und ähnlichen Sonderzeichen ist
ein Zeichenersatz erforderlich; aber die sind ja eh' noch nie im
ASCII-Zeichensatz enthalten gewesen.

Ja, es ist teilweise ASCII aber eben nicht immer...
Ich will die "labels" auch für anderes benützen eben für die
sonderzeichen...

Ich habe noch eine 2. Frage:
Welchen Chip(z.B. von FTDi) brauche ich um USB in UART um zu wandeln
oder muss ich das mit einem virtuellen Serialport über USB lösen ?

Hmm. ASCII ist nur ein 7-Bit-Zeichensatz; die 8-Bit-Erweiterungen sind
erst mit dem ANSI-Zeichensatz (Latin 1, CP1252) standardisiert worden.
Davor gab's verschiedene inkompatible Varianten - IBM-PC (CP437),
Macintosh, VC Amiga ... jeder Homecomputer machte das auf seine eigene
Art und Weise.

Wie auch immer, mit der von mit erwähnten Variante der
Übersetzungstabelle kannst Du in Deinem Quelltext mit ANSI-Codierung
(das ist die unter Windows übliche) arbeiten und konvertierst erst
unmittelbar vor Ausgabe ans Display. Dann musst Du Dir überhaupt keine
Gedanken um irgendwelche "Labels" machen und kannst in Deinem
Assemblerquelltext vernünftig mit Stringkonstanten arbeiten.
Der Geschwindigkeitsverlust dürfte vernachlässigbar sein, lediglich die
256 Bytes Tabelle vergrößern Deinen Code etwas.
Mit etwas mehr Mühe kannst Du die Tabelle auf 128 Bytes schrumpfen,
indem Du in dieser nur die Nicht-ASCII-Zeichen codierst und Zeichen <
0x7F gar nicht erst umwandelst.

Deine zweite Frage ist etwas missverständlich formuliert. Wenn Du einen
Chip von FTDI wie den FT232BM verwendest, dann hast Du auf Deinem PC
eine virtuelle serielle Schnittstelle, die Du mit normalen Programmen
wie eine echte Schnittstelle ansprechen kannst. Am anderen Ende kommen
normale serielle Signale mit TTL-Pegeln 'raus, die sich direkt mit der
UART eines µC verbinden lassen.

Ich will eben kein virtuellen Serialport, hätte lieber direkt USB
->UART.

Ich glaube, hier reden wir aneinander vorbei.

Was präzise stellst Du Dir unter "direkt USB->UART" vor?

Möchtest Du auf dem PC das Ding nicht als serielle Schnittstelle
ansprechen? (Geht, dazu gibt's eine API von FTDI)

Möchtest Du ein völlig eigenes Device-Protokoll verwenden? (Geht nicht
mit FTDI, aber mit zig anderen USB-Device-Controllern, erfordert
Treiberprogrammierung auf PC-Seite)

"Möchtest Du auf dem PC das Ding nicht als serielle Schnittstelle
ansprechen? (Geht, dazu gibt's eine API von FTDI)"

Ja würde ich lieber, da ich dann aber einen Treiber schreiben ist das
zu Aufwendig. Ok hier noch eine Skizze:

PC-USB>>----Irgendwas dazwischen, wofür man keinen Treiber zu schreiben
braucht.-----<<AVR über UART

Es sollte möglichst einfach zu realisieren zu sein.

>  "Möchtest Du auf dem PC das Ding nicht als serielle Schnittstelle
>  ansprechen? (Geht, dazu gibt's eine API von FTDI)"
>
>  Ja würde ich lieber, da ich dann aber einen Treiber schreiben
>  ist das zu Aufwendig.

Von FTDI gibt es eine API (=Programmierschnittstelle), um direkt mit
FTDI-Chips zu kommunizieren. Hier wird keine virtuelle serielle
Schnittstelle verwendet, und es ergeben sich noch weitere Möglichkeiten
("Bit-Bang-Modus" etc.).

Näheres zu API siehe
http://www.ftdichip.com/Documents/ProgramGuides/D2XXPG30.pdf

Damit dürfte Dir geholfen sein.