Forum: Mikrocontroller und Digitale Elektronik VFD Ansteuerung mit STM8

> Die gefundenen Programmbeispiele kann man aber nicht auf
> mein Futaba-Display übertragen.

Ja und? Du hast doch ein Datenblatt. Also lies es und bring das Display
erstmal soweit ans laufen das du etwas auf der Anzeige siehst.

> Kann es sein, dass das VFD-Modul mit dem N8052AH Controller eventuell zu
> langsam für mein Vorhaben ist?

Das musst du dir anhand des Datenblatts ausrechnen. So grob wuerde ich 
aber denken das es es schnell genug ist. Da steht ja sicher drin wie 
schnell du das takten kannst und dann schaust du mal wieviel Bytes du 
fuer einen fullrefresh ausgeben musst. Dann weisst du was erreichbar 
ist.

> Wie würde denn die Grundkonfiguration des STM ungefähr aussehen, wenn
> ich einen Spannungspegel als Bargraph ausgeben möchte?

Du musst die Daten samplen, logarithmieren und dann darstellen. Das 
Problem bei sowas ist das der AD-Wandler von MCUs normalerweise nicht 
die noetige Aufloesung hat. Deshalb logarithmiere ich vorher analog und 
sample dann erst.

> Hat jemand etwas Ähnliches schon mal gemacht?

Ich mache sowas aehnliches mit LCDs welche ein serielles Schieberegister 
haben. Als MCU verwende ich einen STM32F030 pro Kanal. Damit komme ich 
locker auf Refreshrate von 200Hz oder mehr. Das ist nicht unbedingt 
notwendig, aber sieht eleganter aus. Aber 50Hz reicht auch erstmal. Das 
sollte dein kleiner Controller eigentlich auch schaffen. Wenn du also 
mit dem klarkommst dann bleib erstmal dabei.

Olaf

olaf schrieb:
> Ja und? Du hast doch ein Datenblatt. Also lies es und bring das Display
> erstmal soweit ans laufen das du etwas auf der Anzeige siehst.

Das Datenblatt ist wahrscheinlich für die Profis selbsterklärend und 
leicht nachzuvollziehen, ich tue mich als Hobbybastler der wenig Ahnung 
hat eher schwer.
Aber mir hilft es oft ungemein, wenn ich mein Problem hier formuliere.
Immerhin, beim Anlegen von 5V Versorgungsspannung leuchten alle Segmente 
auf mamximaler Helligkeit auf. Beim Testweise-Verbinden eines der 
Datenpins mit dem CTS oder dem RXD-Pin eines MAX232 (am PC-USB 
angeschlossen) zeigt es auch alle möglichen Schriftzeichen an.

Ok, also den Analogteil lasse ich dann erstmal außen vor.
In Software bleibt dann noch der Teil des Samplings/ und ggf. Hold 
(Spannung erfassen/ halten und ausgeben, richtig?) und der 
Segment-Ausgabe als "user defined chararacter" (in meinem Fall je 
Segment ein Block aus 2x7 Pixeln).

Als Datenleitungen habe ich ja nur Clock, Data und Reset. Wie nennt man 
diese Schnittstelle eigentlich?
Clock, Data und Reset sind ja jeweils nur Eingänge, oder?
Um das Display zu betreiben, brauche ich einen Clock-Pulse von 
2us-high/2us-low Pulse-Länge + 40us Gesamtdauer. Das Diagramm mit dem 
Clock-pulse verstehe ich nicht wirklich. Warum schreibt man nicht 
einfach einen gleichmäßigen Clock-Takt vor und warum variiert man diesen 
bzw. was bedeutet der gestrichelte Bereich im Clock-Takt?

Falls es möglich ist, und es keinen großen Aufwand bedeutet - kann evtl. 
jemand ein Programmcode-Beispiel für die Ausgabe des Buchstabens "A" 
machen?

Grüße,
Alex

> Als Datenleitungen habe ich ja nur Clock, Data und Reset. Wie nennt man
> diese Schnittstelle eigentlich?

Syncrone serielle Schnittstelle. Oder auch SPI. Ist aber nicht so 
gernormt wie andere Schnittstellen. Es gibt da unterschiedliche Modi.

http://elm-chan.org/docs/spi_e.html

Olaf

olaf schrieb:

> Syncrone serielle Schnittstelle. Oder auch SPI. Ist aber nicht so
> gernormt wie andere Schnittstellen. Es gibt da unterschiedliche Modi.

Genau. Das hier ist SPI-Mode1.

Allerdings nicht "pure". Die Wartezeit von einem halben Takt ist nicht 
direkt SPI-like. Allerdings: viele reale SPI-Hardware hat sowieso eine 
Art Zwangspause von einer Bitdauer nach jeden Datenwort. Inwieweit das 
auch auf den STM8 zutrifft entzieht sich allerdings meiner Kenntnis.

Das soll der TO selber aus dem Datenblatt ermitteln. Ist sein Projekt 
und er selber hat sich aus unerfindlichen Gründen für STM8 
entschieden...

c-hater schrieb:
> Ist sein Projekt
> und er selber hat sich aus unerfindlichen Gründen für STM8
> entschieden...

Naja, vielleicht hat er noch ne Tüte davon in seiner Bastelkiste und 
will sie nicht ganz und gar sedimentieren lassen. Geht mir gelegentlich 
ähnlich, zwar nicht mit STM8, aber vom Prinzip her.

Und zum TO:
Du willst etwas ausprobieren, hast auch die Dokumentation, suchst aber 
nach etwas Fertigem zum Kopieren anstatt die Doku zu lesen und zu 
verstehen und etwas dabei zu lernen. Hmm...

W.S.

Vielen Dank für die Beispiel Routine, Matthias!
Zum Einstieg in die Theorie zum bit banging vs. hardware SPI hab ich 
einiges gefunden. Ich könnte mir vorstellen, dass es eigentlich genauer 
und schneller wäre, das SPI in hardware zu machen (jitter), aber 
inwieweit das wirklich relevant ist. Das wäre dann was für später, wenn 
alles läuft.

Auf dieser Seite wird das Betreiben eines LCDs mit dem STM8 sehr 
ausführlich beschrieben.
https://embedded-lab.com/blog/continuing-stm8-microcontroller-expedition/14/

Kann ich mir hier vielleicht etwas abschauen?
Ich bin wie gesagt Hobby-Bastler ohne längere Erfahrungen mit 
Mikrocontrollern.
Beim definieren der GPIOs gehts schon los... Was ist denn der GPIOD?
(#define LCD_PORT                        GPIOD)
Die anderen Pins kann ich zuordnen und ich bin gerade dabei, das Ganze 
auf meinen Testaufbau zu übertragen.

W.S. schrieb:
> willst etwas ausprobieren, hast auch die Dokumentation, suchst aber
> nach etwas Fertigem zum Kopieren anstatt die Doku zu lesen

Ich glaube es geht dem ein oder anderen Anfänger ähnlich - wenn man ein 
Beispiel vor sich hat, geht es manchmal besser voran als mit nem leeren 
Blatt Papier.

> Ich glaube es geht dem ein oder anderen Anfänger ähnlich -

WAs dir und anderen Anfaengern fehlt ist nicht das Internet und damit
die Moeglichkeit bestimmtes Detailwissen einzusehen oder andere Arbeiten
abzugreifen. Du brauchst ein Buch das dich komplett an die Hand nimmt 
und dir das Wissen didaktisch aufbereitet in sinnvoller Reihenfolge und 
aufbauend beibringt. Alles andere ist zum Scheitern verurteilt.

Olaf

olaf schrieb:
> Du brauchst ein Buch das dich komplett an die Hand nimmt

Ähem... an die Hand? Es wäre mMn wesentlich sinnvoller, das Buch ZU 
LESEN. Und zwar um es zu verstehen.

W.S.

> Ähem... an die Hand?

Wenn du schon so wenig Gehirnzellen fuer Freundlichkeit bereitstellen 
willst, warum nicht ein paar fuer das Verstaendnis von Metaphern opfern?

Olaf

Hallo,

Was die GPIOs und Ports sind (Port A,B,C und D) und wo sich diese bei 
meinem Aufbau hardwaremässig befinden (D4/5/6 = Pin 1/2/3 am STM8 im 
TSSOP20) habe ich klären können:)
Auch hab ich meine beiden "custom characters" für die Balkenanzeige in 
Binärschreibweise aufschreiben können:)

Zu den Abkürzungen hier:
STB = stop bit = Reset
SCK = Clock
SDI = Data
- das müsste passen?

Hier nochmal der LCD-Code auf den ich mich beziehe:
https://embedded-lab.com/blog/continuing-stm8-microcontroller-expedition/14/

#include "stm8s.h"
#define LCD_PORT                        GPIOD
#define LCD_STB_pin                     GPIO_PIN_4
#define LCD_SCK_pin                     GPIO_PIN_5
#define LCD_SDI_pin                     GPIO_PIN_6

ich habe mir vorhin auch mal alle Kommandos des VFDs in die 
"0x00"-Hexadezimalschreibweise übersetzt. Dabei ist mir aufgefallen, 
dass die Kommandos vom LCD fast überhaupt nicht mit denen der VFDs 
übereinstimmen.
Wahrscheinlich kann ich dann vieles weglassen, oder?

Dieser Teil wird so übernommen, oder?
#define LCD_STB_HIGH()                  GPIO_WriteHigh(LCD_PORT, 
LCD_STB_pin)
#define LCD_STB_LOW()                   GPIO_WriteLow(LCD_PORT, 
LCD_STB_pin)
#define LCD_SCK_HIGH()                  GPIO_WriteHigh(LCD_PORT, 
LCD_SCK_pin)
#define LCD_SCK_LOW()                   GPIO_WriteLow(LCD_PORT, 
LCD_SCK_pin)
#define LCD_SDI_HIGH()                  GPIO_WriteHigh(LCD_PORT, 
LCD_SDI_pin)
#define LCD_SDI_LOW()                   GPIO_WriteLow(LCD_PORT, 
LCD_SDI_pin)

Von hier an stimmt, so wie ich das sehe, nur "clear display" 
(VFD-Kommando Nr. 1 > 01H > 0x01) überein.
Ansonsten kann ich nichts vom LCD-Code übernehmen, richtig?

#define clear_display                  0x01
#define goto_home                      0x02
#define cursor_direction_inc           (0x04 | 0x02)
#define cursor_direction_dec           (0x04 | 0x00)
#define display_shift                  (0x04 | 0x01)
#define display_no_shift               (0x04 | 0x00)
#define display_on                     (0x08 | 0x04)
#define display_off                    (0x08 | 0x02)
#define cursor_on                      (0x08 | 0x02)
#define cursor_off                     (0x08 | 0x00)
#define blink_on                       (0x08 | 0x01)
#define blink_off                      (0x08 | 0x00)
#define _8_pin_interface               (0x20 | 0x10)
#define _4_pin_interface               (0x20 | 0x00)
#define _2_row_display                 (0x20 | 0x08)
#define _1_row_display                 (0x20 | 0x00)
#define _5x10_dots                     (0x20 | 0x40)
#define _5x7_dots                      (0x20 | 0x00)
#define dly                            2
#define DAT                              1
#define CMD                              0
extern unsigned char data_value;
void SIPO(void);
void LCD_init(void);
void LCD_toggle_EN(void);
void LCD_send(unsigned char value, unsigned char mode);
void LCD_4bit_send(unsigned char lcd_data);
void LCD_putstr(char *lcd_string);
void LCD_putchar(char char_data);
void LCD_clear_home(void);
void LCD_goto(unsigned char x_pos, unsigned char y_pos);

Wie starte ich eigentlich das "Programm" auf dem STM8? Kann man das per 
Knopfdruck und zusätzlichem Code machen, oder läuft das einfach los, 
wenn eine Versorgungsspannung anliegt?

Danke für Eure Hilfe bisher, aber ich sehe schon, man muss sich wirklich 
selbst da durchwühlen. Trotzdem wäre es ganz ohne Unterstützung noch 
schwerer.

Viele Grüße,
Alex

Matthias S. schrieb:
> Alex schrieb:
>> oder läuft das einfa

Pullupwiderstand 10k am Ach los,
>> wenn eine Versorgungsspannung anliegt?
>
> Das wäre der Normalfall. Aber wir wissen ja nix von deiner Hardware -

Es braucht:

- Pullupwiderstand am Anschluß NRST
- Kondensator 1 uF gegen Ground am Anschluß VCAP
- Abblockkondensator 100 nF über der Betriebsspannung nahe an den 
Anschlüssen des Controllers

Danach legt das Teil mit anlegen der Betriebsspannung automatisch los. 
Ein (kurzes) anlegen eines LOW-Pegels am NRST setzt den Controller 
zurück (Reset eben).

Allerdings:

Alex schrieb:
> Ein ST-Link V2 ist vorhanden und die
> Programmierung funktioniert generell :)

Wenn man den anschließen kann, sollte man auch wissen, wie der 
Controller "startet"

jjflash schrieb:
>> Ein ST-Link V2 ist vorhanden und die
>> Programmierung funktioniert generell :)
>
> Wenn man den anschließen kann, sollte man auch wissen, wie der
> Controller "startet"

Es ist Zufall, dass ich den STM8 nutzen will. Hatte noch einen RPM-Meter 
mit STM8 übrig, dessen Displaypins ich durch zwei Stiftleisten ersetzt 
habe - als quasi Entwicklungsboard :)
SWIM und NRST waren auch schon herausgeführt, man musste nur noch eine 
Stiftleiste anlöten.
Der 10k von NRST an Vcc, der Abblock-C und der Kondensator an Vcap ist 
schon drauf. Hänge den groben Schaltplan mal an (Displaypins= JP1/JP2, 
Hallsensor am Kabel ist nicht mit drauf).

Der STM8 wird ja allgemein eher gelobt, daher dachte ich, dass ich den 
nutzen kann. Hätte ich die freie Wahl gehabt, hätte ich zB. auch eher 
einen PIC -Mikrocontroller gewählt, aber wirklich besser wäre der dann 
auch nicht, oder?
Inwiefern sind eigentlich die Programme der verschiedenen Controller 
später untereinander kompatibel, bzw. kommt es nur auf die 
Programmiersprache oder eher auf die Eigenarten der Controller an 
(Beispiel STM/PIC)?

Alex schrieb:
> Dieser Teil wird so übernommen, oder?
> #define LCD_STB_HIGH()     GPIO_WriteHigh(LCD_PORT, LCD_STB_pin)
> #define LCD_STB_LOW()      GPIO_WriteLow(LCD_PORT, LCD_STB_pin)
> ... usw.

Ich frag mich seit langem, wieso die Leute hier sowas hinschreiben. Es 
ist wohl doch die Hochmut-Kuh, die da zugebissen hat. Oder eben eine 
unsägliche Angst davor,_selber_ auf die bekannten Register des Chips 
zuzugreifen.

Bedenke mal, daß du mit deinen Zeilen zwar eine Textersetzung 
vorgenommen hast, aber anstatt das Portpin zu setzen eine 
Bibliotheksfunktion aufrufst, die dann auch noch 2 Argumente benötigt, 
die ihrerseits von Anfang an bereits feststehen. Also 2 Werte laden und 
auf den Stack oder in Register schaufeln, die Funktion aufrufen und die 
muß dann die Argumente bewerten, um auf den gewünschten Port zu kommen 
und dort das gewünschte Pin zu setzen. Und das für die Verwendung 
INNERHALB eines Lowlevel-Treibers, der ohnehin plattform- und 
projektabhängig ist. Viel Umweg für wenig Nutzen.

Wieviel einfacher und auch geradliniger ist es, etwa sowas zu schreiben:

1

#define StrobePin 6

2

3

void Strobe_low (void)

4

{ GPIOD_BRR = 1<<StrobePin; }

5

6

void Strobe_high (void)

7

{ GPIOD_BSRR = 1<<StrobePin; }

8

9

... usw.

Ich habe hier mit BRR und BSRR etwas aus der Cortex-Kiste bzw. STM32 
entnommen. Das müßtest du an deinen Chip anpassen. Und dann kannst du 
als allerersten Schritt diese Funktionen ausprobieren, ob sie auch das 
tun, was du haben willst. Als nächstes könntest du ein 'inline' 
dazuschreiben und damit auch den Call beseitigen.

Du programmierst hier einen µC, wo man es direkt mit den auf dem Chip 
vorhandenen Hardware-Teilen zu tun hat - und nicht für einen PC, wo es 
ein OS gibt, das Hardwarezugriffe nicht zuläßt, weswegen man dort nur 
das benutzen kann, was das vom OS gebotene API hergibt.

W.S.

Alex schrieb:
> Inwiefern sind eigentlich die Programme der verschiedenen Controller
> später untereinander kompatibel, bzw. kommt es nur auf die
> Programmiersprache oder eher auf die Eigenarten der Controller an
> (Beispiel STM/PIC)?

Also, ich versuche mal, eine klaffende Grundlagenlücke bei dir etwas zu 
verkleinern.

Verschiedene Architekturen sind eben verschieden aufgebaut und haben 
auch verschiedene Sätze von Maschinenbefehlen, die eben zur jeweiligen 
Architektur passen.

Ganz grob kann man Architekturen in 2 Gruppen teilen:
Harvard-Architektur, wo es für Instruktionen und Daten getrennte 
Adreßräume gibt
VonNeumann-Architektur, wo es nur einen gemeinsamen Adreßraum für 
Instruktione und Daten gibt.

Darüber hinaus gibt es von der Verarbeitung der Daten her zwei 
verschiedene Ansätze:
1. Sorte: Mit einer CPU, die Register für die Daten hat, wo man zum 
Bearbeiten eine Folge von Schritten tun muß:
- Laden der Daten vom RAM ins Register
- Bearbeiten des Registers
- Speichern der Daten vom Register in den RAM

2. Sorte: Mit einer CPU, die eben keine Register für die Daten hat, wo 
also das Ergebnis quasi direkt im RAM erzeugt wird. Das braucht dann nur 
einen Maschinenbefehl dafür.

Es haben beide Ansätze ihre Vor- und Nachteile und man trifft auch beide 
als Chips an. Die PIC16 sind z.B. Harvard und von de CPU her von der 
2.Sorte. Die PIC32 sind hingegen das komplette Gegenteil.

So, das war ein bissel zu den Hardwaregrundlagen.

Programmierung:
Man unterscheidet seit langem 2 Sorten von Programmiersprachen: 
maschinenabhängige und maschinenunabhängige. Von der ersteren Sorte ist 
eigentlich nur Assembler übriggeblieben. Da ist eigentlich nur jedem 
Maschinenbefehl ein möglichst gut zu merkender Name (wird hier oft 
Mnemonik genannt) zugeordnet.
Also anstelle 0C3h 57h 0E0h
lieber sowas  JMP Kaltstart

Bei den maschinenunabhängigen Sprachen bedarf es eines 
Übersetzungsprogrammes (zumeist Compiler genannt), das für die 
jeweiligen Sprachelemente der jeweiligen Sprache eine Folge von 
Maschinenbefehlen für die Maschine macht, wo das Programm dann mal 
laufen soll. Da die Sprache aber maschinenunabhängig sein soll, kann sie 
keine Spezialitäten einer bestimmten Maschine berücksichtigen. Dafür 
gewinnt man aber an Portabilität, wenn man sauber zwischen den 
eigentlichen Algorithmen und den Lowlevel-Treibern trennt. Zum Portieren 
braucht man dann nur noch die Lowlevel-Dinge an eine andere Maschine 
anzupassen - vorausgesetzt, das ganze Zeugs ist generell überhaupt 
portierbar.

W.S.

Matthias S. schrieb:
> Sicher wäre es einfacher, wenn du dich nicht ausgerchnet mit so einer
> selteneren MC Familie wie STM8 beschäftgien würdest. Da gibts hier nicht
> so viele Kenner.

Ich bin mittlerweile auch zur Einsicht gekommen, dass ich definitiv 
einen PIC nehmen muss. Als Anfänger gibt es einfach zu viele Baustellen.
Aber auch bei den PICs finde ich relativ wenige Beispielcodes im Netz.
Zu meinem speziellen Thema SPI/"3 wire"- VFD existiert sehr wenig.
Falls jemand noch Seiten zu VFD-Projekten oder Infos hat, wo man sich 
vielleicht was abschauen könnte - dann gerne hier posten.:)
Man kann anhand einem funktionierendem Projekt mit ungefährer Anleitung 
eher zu einem Ergebnis kommen, auch wenn der Lerneffekt wahrscheinlich 
nicht besonders groß ist. Erstmal soll ja nur die Verbindung zwischen 
PIC und VFD laufen und wenigstens ein paar im Programm gesetzte Zeichen 
aufleuchten.
Das wäre dann schon ein richtiger Erfolg :)

Zumindest weiß ich jetzt, was Ports sind und kann Hex/Binärschreibweise 
übersetzen.
Was empfehlt ihr? Spricht etwas dagegen, einen eher "alten" PIC aus der 
Zeit des Displays zu nehmen (Mitte der 90er)? Der beliebteste PIC ist 
angeblich der PIC16F54 und der PIC16F84 oder der PIC16F886/7. 
Programmieren würde ich den mit dem TL866 Programmer.

Viele Grüße und vielen Dank für die ganzen wertvollen Infos!
Alex

Ob du eine STM8/PIC/AVR verwendest, ist eigentlich egal. Viel wichtiger 
ist die Verfügbarkeit von einer state-of-the-art Umgebung. Normalerweise 
benutzt man dazu die zum Controller gehörige IDE (weil meist umsonst) in 
Verbindung mit einem Debugger, welcher in-system wirkt. Umstecksessions 
mit TL866 hören sich so 90er an. Zudem ist es hilfreich, wenn die IDE 
einen Simulator mitbringt. Da kannst du trocken ein paar Codezeilen 
testen ohne den Flash abzutragen.

Debugger kosten Geld. Für kleines Geld einen stlink-clone von aliexpress 
und beim STM8 geht es vorwärts. PIC/AVR mittels SNAP für topaktuell oder 
Pickit 3 von ali für die etwas älteren PICs.

Werkel selbst gerade an einer dualen Umsetzung. Von AVR um STM8 
erweitert. Der STM gewinnt unter SDCC knapp bei der Binärgröße. Und ob 
ein Pin nun mittels "PORTB |= (1 << PB3)" oder "GPIOB->ODR |= (1 << 3)" 
angesteuert wird, ist für den Grundalgorithmus eigentlich egal.

Und lass die Finger von den alten 16F54. Damit beschränkst du dich 
selbst, wo du nicht musst.