Post subject: Schriftdarstellung auf seriellem grafischem Display
Posted: 2003-07-09 22:53:24
Replies: 16 Views: 1681
Wolfgang Berger schrieb:
>>weisst Du, ob der Displaycontroller eigenen Speicher hat oder nicht?
>
>
> Nur Ram für den aktuellen Displayinhalt. Keinen Speicher für
> Zeichensätze.
>
>
>>200 Zeichen halte ich für ziemlichen Luxus.
>
>
> Ok. Aber 100 sind auf jeden Fall nötig. Dann benötige ich immer
noch 15K
> Speicher.
>
>
>>Bist Du sicher, dass die Zeichenmatrix quadratisch sein muss?
>>Ich behaupte REcheckig fährst Du besser (Must Du ausprobieren).
>
>
>>Müssen die Zeichen 16 bzw. 32 Pixel hoch sein? (Es ist recht
sinnfrei,
>>leere Zwischenräume zwischen den Zeichen / Zeilen mit
abzuspeichern).
>
>
>
> Die Größenangaben waren nur zur groben Abschätzung. Es
soll später keine
> Schrift mit fester breite genutzt werden. Ich könnte zum Beispiel in
den
> ersten beiden Bytes die Breite abspeichern. Allerdings gewinne ich
> dadurch nicht viel, da ich immer diese 2 Bytes Overhead habe.
Hallo Wolfgang. warum schliesst Du nicht jedes Zeichen mit einer Null
ab? --> Overhead 1 Byte pro Zeichen. Ausserdem kannst Du durch einfaches
Nullen Zählen das Zeichen finden, und Sparst Dir so ein Inhaltsverzeichis.
Auch wenn die Breite der Schrift variabel ist, so sollte doch die Höhe
gleich sein. Und es ist doch einen Unterschied, ob Du eine matrix von
16x8 oder 14x8 Pixel hast. Mach Dir mal Gedanken, wie gross die Zeichen
sein sollen, dann weisst Du auch, welchen Speicherplatz Du benötigst.
Mach Dir auch Gedanken, wie der Displaycontroller organisiert ist, das
Spart Usortierarbeiten in der Software (unter C gesht Du bei so was fast
am "Stock").
>
>
>
>>Anfangen würde ich mit dem 16x16 Zeichensatz, anschliessend mal
>>versuchsweise hochskalieren und dann prüfen, ob sich das ergebnis
>>angucken lässt.
>
>
> Werde ich mal versuchen. Den kann ich nämlich noch im Speicher des
PIC
> unterbringen. Allerdings schätze ich, dass beim einfachen
hochskalieren
> 1Pixel -> 4 Pixel die Schrift nicht mehr so toll aussieht. Einen
Versuch
> ist es aber auf jeden Fall wert.
>
> Gruß
> Wolfgang
Post subject: Schriftdarstellung auf seriellem grafischem Display
Posted: 2003-07-09 22:53:32
Replies: 16 Views: 1681
Hallo Georg
Vergiss die TTF Fonts von Windows. Wenn Du diese Schriftarten in der
geforderten Pixelgrösse ausliest, dann sieht das einfach furchtbar aus.
Das beste ist immer noch, de Buchstaben Pixel für Pixel zu designen oder
eine Bitmap-Schrift mit entsprechend niedriger auflösung zu wählen.
Gruss Jochen
Georg Meister schrieb:
>>Ist diese Vorgehensweise sinnvoll, oder gibt es bessere
Möglichkeiten,
>>zum Beispiel fertige Schriftsatz Speicher ?
>>Sollte die kleinere Schrift durch schrumpfen der großen dynamisch
>>erstellt werden ? Zum Beispiel zusammenfassen von 4 Pixeln. Bei >2
>>schwarz, wir der Pixel schwarz dargestellt, bei <=2 weiß.
>>
>>Bekomme ich irgendwoher fertige Zeichensätze gratis oder relativ
>>günstig, oder muss ich diese komplett selbst erstellen ?
>
>
>
> Am PC mit Visual Basic den kompletten Zeichensatz für eine Schriftart
> und -grösse deiner Wahl anzeigen, pixelweise auslesen und geeignet
> abspeichern. Das sind nur ein paar Zeilen Code und du kannst die Tabellen
> gleich als HEX-Datei oder ASM oder C-Source abspeichern.
>
> Wenn es gut aussehen soll, Proportionalschriften verwenden und die
Schriften
> inkl. der Antialiasing-Graustufen speichern, was die Lesbarkeit sehr
erhöht.
>
> Die Zeichensätze in den benötigten Grössen in einem
seriellen EEPROM oder
> FLASH-PROM ablegen, billig, ausreichend Platz und einfach anzuschliessen.
>
> Georg
>
>
Post subject: Schriftdarstellung auf seriellem grafischem Display
Posted: 2003-07-10 23:52:09
Replies: 16 Views: 1681
Hallo,
ich denke, es ist einfacher, aus dem Datenblatt eines Dot-Matrix
Controllers z.B. Hitacht HD 44780 oder so den Zeichensatz abzumalen, und
zu skalieren und anschliessend mit einigen Pixeln noch ein wenig
Schönheitsoperation betreiben.
Post subject: Kritische Probleme mit PIC16F648A !!!
Posted: 2003-07-09 22:53:36
Replies: 15 Views: 2076
Hallo Grzegorz,
Meine Glaskugel sagt mir, dass das nach Problemen mit der
Bankumschaltung aussieht. Im Ram kommst Du gelegentlich an der Bank 1
vorbei und änderst das TRistate-register, vielleicht hast Du auch irgend
eienn Speicherüberlauf und landest wieder im Tristate-Regster......
Könnte es auch sein, dass du das PC-Lath-Register nicht korretk
verarbeitest (nicht sichern bei Interrupts,etc....)
Mit welcher Programmiersprache /Compiler arbeitest Du?
Post subject: Kritische Probleme mit PIC16F648A !!!
Posted: 2003-07-10 23:47:11
Replies: 15 Views: 2076
Hallo,
vom CCs-Compiler, mit dem ich gearbeitet habe, halte ich nicht
sonderlich viel:
Für kleine Projekte, Quick and Dirty Programmierung ist der geeignet,
bei Grossprojekten würde ich die Finger weglassen. Der einzige Vorteil
neben dem Preis beim CCS ist, das für die Üblichen
Anwendungsfälle
(Serielle Schnittstelle, I2C-Bus) schon was vordefiniert ist.
Die Nachteile wären: Optimierung mangelhaftt, Support: fehlanzeige.
Beim HiTch-Compiler ist das eine Frage der Zeit, bis der PIC eingebaut
wird, zumal dieser Compiler von Microchip offiziell unterstützt /
empfohlen wird. Neben kompaktem Code gibt es in Deutschland sehr
kompetenten Support für diesen compiler. Der einzige Nachteil ist
eigentlich, dass dieses ein Richtiger, reiner ANSI-C- Compiler ist.
I2C-Bus, bitverarbeitung kennt dieser aus diesem Grunde von Haus aus
nicht, das muss halt nachgerüstet werden.
Post subject: Kritische Probleme mit PIC16F648A !!!
Posted: 2003-07-14 23:00:27
Replies: 15 Views: 2076
Hallo Heiko,
ich hatte mal die Freude, für ein Projekt mit dem 16F73 mehrere Compiler
zu Benutzen.
Angefangen habe ich mit Assembler, den ich dann auch noch für die
Stromsparvariante verwende.
Weiter (da Forderung Programmierung in C) gings mit CCS-compiler.
Nachdem ich 50% des Projektes realisiert habe, war der Speicher voll.
Ausserdem habe ich festgestellt, dass der Compiler bei der
Interruptverarbeitung mehr Maschinenbefehle benötigt, bis der
eigentliche Interrupt-Code abgearbeitet wird, wie die Gesamte
Interrupt-Routine in Assembler umfasst.
Geendet bin ich dann beim Hitec C-Compiler.
Die Interruptbearbeitung hat Assembler-Qualität, Support ist erstklassig
(Problemlösung in Deutsch und im Stundenbereich).
Aber wie geschrieben, letztendlich musst Du selbst wissen, welche Kröte
Du schlucken willst
Post subject: PIC16F648A - Interner krotischer Fehler
Posted: 2003-07-21 22:53:13
Replies: 9 Views: 2431
Hallo Grzegorz,
Könnte es vielleicht sein, dass die Assembler-Routinen probleme machen?
Ich könnte mir folgendes Vorstellen:
Asselmblerroutine geht über eine Seitengrenze hinweg. Da passiert ja
weiter nix, PCLATH wird automatisch gesetzt. Dann kommt ein Sprung über
die Seitengrenzen zurück, PCLATH wird nicht gesetzt, wo der Sprung dann
endet,...
Atmel fertigt noch Funkempfänger. Ob die genau den Typ fertigen, den Du
haben willst weiss ich nicht. Grundsätzlich werden so viele Gefertigt,
dass die verkauft werden. Frag mal bei Spoerle nach, die haben auch
Liefermengen Unterhalb Rolle.
der PIC 16F77 hat einen I2C-Slave eingebaut.
Beim 16F73 (kleiner Bruder vom 16F77) habe ich diesen I2C-Bus slave in
Assembler und C (HITEC) zum laufen gebracht. Wenn ich es richtig weiss,
ist im Datenbuch ein Programm abgedruckt. Notfalls kannst Du auch das
Midrange Reference Manual zu rate ziehen. Ob es eine Application-Note
gibt weiss ich nicht. Fals ja, Kannst Du Beispiele vom 16F73, 16F74 ,16F
76 sowie den entsprechenden C-Varianten (16C73,a,b, 16C74, 16C76, 16C77)
übernehmen.
Die Geschwindigkeit des Entflechtens ist proportional abhängig von der
zur Verfügung stehenden Platinenfläche. Zusätzliche
Versorgungslagen
wirken sich zeitmindernd aus.
Also die ICs auf einer 6-Lagen Multilayer-Leiterplatte zu Verteilen und
zu Routen ist kein Problem...
Schöner wirds dann schon, wenn die ICs dicht gepackt sind, oder wenn
die Leiterplatte nicht dem Rechteckförmigen Ideal entspricht....
Bibliotheken ist normalerweise kein grosses Thema, wenn das IC nicht
vorgefertigt ist, dann ist in der Regel (bei Vernünftigen Programmen)
das Gehäuse vorhanden. Wenn Du eien Schaltplan benötigst, ist recht
schnell ein Rechteck mit vielen Anschlüssen gezeichnet.
Die Routdauer der Leiterplatte hängt von Randbedingungen wie die
Grösse
der Leiterplatte, Form der Leiterplatte und Anzahl der Lagen ab.
Eine Stunde ist knapp bemessen, im Akkord könnte es Reichen. Es kommt
auch noch darauf an, wie die ICs und die anderen Bauteile miteinander
verbunden werden sollen.
You can post new topics in this forum You can reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum