Forum: Mikrocontroller und Digitale Elektronik VFD Ansteuerung mit STM8


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Alex (Gast)


Lesenswert?

Hallo,

ich suche nach einer Möglichkeit, ein VFD-Modul (Futaba US162S) mit 
einem STM8S003F3 anzusteuern. Erstmal wäre ich froh, überhaupt eine 
Kommunikation hinzubekommen. Ein ST-Link V2 ist vorhanden und die 
Programmierung funktioniert generell :)
Ich habe schon allgemein nach LCD-Ansteuerungen (die ja recht ähnlich 
sein sollten?) gesucht und mir einige Beispiele angeschaut. Die 
gefundenen Programmbeispiele kann man aber nicht auf mein Futaba-Display 
übertragen.
Hier das Futaba Datenblatt:
https://www.allelectronics.com/mas_assets/media/allelectronics2018/spec/VFD-162.pdf

Hier die library:
https://github.com/Andy4495/FutabaVFD162S

Meine Idee war, mit dem VFD ein kompaktes Audio-Pegelmessgerät zu 
realisieren, je nach Sinnhaftigkeit und Komplexität - entweder mit 
analoger Peak-Gleichrichtung und analoger Logarithmierung oder aber 
beides per Software im STM. Im Netz sieht man viele wild flackernde 
Peak/VU-Meter, die hauptsächlich alles in Software erledigen und 
entweder viel zu schnell flackern (keine Fall-back-time) oder zu träge 
reagieren. Daher dachte ich mir, dass hier die analogen Stufen von 
Vorteil sind und Signalverarbeitung so auf jeden Fall schnell und genau 
genug ist. Analoge Schaltungsbeispiele für Peak/-Gleichrichtung und 
Logarithmierung sind ebenfalls vorhanden.
Das Ganze muss nicht unbedingt Messgerätecharakter haben und der 
Anzeigeumfang (ca. 50dB maximal, mehr macht fast keinen Sinn bei der 
Größe?) muss auch nicht unbedingt riesig sein.
Ich kann den STM8 Mikrocontroller nicht wirklich einschätzen, aber ich 
denke schon, dass er für die Umsetzung ganz gut passen müsste, oder?
Kann es sein, dass das VFD-Modul mit dem N8052AH Controller eventuell zu 
langsam für mein Vorhaben ist?

Ähnlich wie hier gezeigt, möchte ich das Display in 2x32 Balken 
aufteilen:
https://maker.pro/arduino/projects/diy-arduino-vfd-display-20x2-vu-volume-unit-meter

Wie würde denn die Grundkonfiguration des STM ungefähr aussehen, wenn 
ich einen Spannungspegel als Bargraph ausgeben möchte?
Hat jemand etwas Ähnliches schon mal gemacht?

Ich danke Euch schon einmal für Eure Hilfe,

Viele Grüße,
Alex

von olaf (Gast)


Lesenswert?

> 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

von Alex (Gast)


Lesenswert?

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

von olaf (Gast)


Lesenswert?

> 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

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

STM8, soso. Ich poste dir mal eine Routine, die per Bitbanging 8 bit per 
SPI auf ein DOGM Display schiebt. Das ist AVR8, sollte aber so gut wie 
auf jedem MC laufen:
1
// LCD connections
2
#define LCD_PORT PORTB
3
#define LCD_DIR  DDRB
4
#define LCDDATA 1
5
#define LCDCLK 2
6
#define LCDA0 3
7
#define LCDCS 0
8
#define LCD_MASK ((1<<LCDDATA)|(1<<LCDCLK)|(1<<LCDA0)|(1<<LCDCS))
9
10
// LCD routines by bit banging as we have no more pins to use the hardware SPI
11
void lcd_out(const uint8_t data) {
12
uint8_t n = 8;
13
uint8_t shifter = data;
14
 LCD_PORT &= ~(1<<LCDCS);    // select LCD
15
    while (n>0) {
16
    LCD_PORT &= ~(1<<LCDCLK);  // clk lo
17
      if (shifter & 0x80) LCD_PORT |= (1<<LCDDATA);
18
     else LCD_PORT &= ~(1<<LCDDATA);
19
    shifter <<= 1;
20
      LCD_PORT |= (1<<LCDCLK);  // clk high
21
    n--;
22
    }
23
 LCD_PORT |= (1<<LCDCS);    // deselect LCD
24
}
Nur eine von dutzenden Möglichkeiten. Da kannste auch eine for-next 
Schleife oder was auch immer benutzen.

: Bearbeitet durch User
von c-hater (Gast)


Lesenswert?

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...

von W.S. (Gast)


Lesenswert?

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.

von Alex (Gast)


Lesenswert?

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.

von Andreas H. (ahz)


Lesenswert?

Alex schrieb:
> Beim definieren der GPIOs gehts schon los... Was ist denn der GPIOD?
> (#define LCD_PORT                        GPIOD)

Huhu

Das ist (vermutlich) der Port D des Controllers. Ich war jetzt zu faul 
selber mal im Includefile nachzusehen ob da evtl was extra definiert 
wurde.

Aber, ohne Dir zunahe treten zu wollen, bist Du sicher dass es Sinn 
macht so ein Projekt zu starten wenn Du nicht mal rauskriegst was GPIOD 
ist?
Da fehlen vielleicht doch ein paar Grundlagen?

/regards

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Andreas H. schrieb:
> Da fehlen vielleicht doch ein paar Grundlagen?

Da kann man aber entgegenhalten, das man an der Aufgabe wächst.

Alex schrieb:
> Ich könnte mir vorstellen, dass es eigentlich genauer
> und schneller wäre, das SPI in hardware zu machen (jitter)

Kannste knicken. Erstens ist Jitter bei einem VFD Chip wurscht und 
zweitens ist ja das CLK von SPI genau zur Synchronisation.
Bitbanging geht halt auf jedem MC, zu Hardware SPI musst du genau das 
Datenblatt studieren.

: Bearbeitet durch User
von olaf (Gast)


Lesenswert?

> 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

von W.S. (Gast)


Lesenswert?

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.

von olaf (Gast)


Lesenswert?

> Ä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

von Alex (Gast)


Lesenswert?

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

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Alex schrieb:
> oder läuft das einfach los,
> wenn eine Versorgungsspannung anliegt?

Das wäre der Normalfall. Aber wir wissen ja nix von deiner Hardware - 
ausser, das da ein VFD an irgendein MC Board mit STM8 angeschlossen sein 
soll. Zur Bedienung des MC Boards solltest du die Unterlagen dazu 
konsultieren.

Alex schrieb:
> aber ich sehe schon, man muss sich wirklich
> selbst da durchwühlen.

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 z.B. weiss nur, das die Dinger gerne mal in 
chinesischen Standheizungen arbeiten.

: Bearbeitet durch User
von jjflash (Gast)


Lesenswert?

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"

von Alex (Gast)


Angehängte Dateien:

Lesenswert?

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)?

von W.S. (Gast)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

Alex schrieb:
> Inwiefern sind eigentlich die Programme der verschiedenen Controller
> später untereinander kompatibel

In C kann man recht gut die hardwarenahen Zugriffe vom funktionalen Code 
trennen und hat damit den Großteil des Codes auf andere CPUs portierbar.

Speziell beim AVR-GCC recht praktisch ist die "delay.h", mit der man die 
ganzen µs-Zeiten lt. Datenblatt des VFD bequem implementieren kann. 
Leider ist eine ähnliche Library für viele andere Architekturen nicht 
verfügbar.

Die PIC kann man nicht alle in einen Topf werfen, da sie recht krasse 
Unterschiede aufweisen. Eigentlich sind erst die PIC18 und höher auch 
gut in C programmierbar. Die kleineren haben z.B. einen sehr reduzierten 
Befehlssatz, limitierten Hardwarestack, lückende RAM-Bereiche und 
segmentierten Flash als Nachteile.

Mit dem STM8 hab ich keine Erfahrungen.

Das VFD hat schon ein recht eigenartiges Protokoll mit 2 Modi. Mode 1 
sieht einfacher aus und läßt sich mit dem HW-SPI realisieren. Mode 2 
könnte aber fehlertoleranter sein (Resynchronissation nach 
Störimpulsen).

von Alex (Gast)


Lesenswert?

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

von neuer PIC Freund (Gast)


Lesenswert?

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.

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]
  • [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.

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