Im Rahmen eines Spaßwettbewerbes um den "billigsten BASIC-Computer"
aller Zeiten entstanden:
"Für die einen ist es ein Microcontroller, für die anderen der
wahrscheinlich billigste BASIC-Computer der Welt"
Mein Basiccomputer läuft in einem STM8S103 Minimumboard aus China (2
Stück für 1,53):
Ebay-Artikel Nr. 272151798778
und ist an eine CH340G USB2RS232 angebunden:
Ebay-Artikel Nr. 272258438888
Wenn man den "Mengenrabatt" aus China mitnimmt, kostet ein
"BASIC-Computer" 1,65@ (siehe README.TXT).
Das Projekt ist als reines Editor / Make Projekt unter Linux entstanden
und wird mit dem SDCC 3.50 übersetzt.
Im Zip-Archiv sind sämtliche Dateien enthalten, um die Firmware zu
erstellen.
Im Ordner basict das Makefile aufrufen mit:
make all
(Um die Firmware zu erstellen)
make flash
(Um die Firmware mittels eines ST-Link v2 zu übertragen).
Vllt. mache ich auch nur so aus Gag auch noch eine Miniplatine für
diesen Zwerg.
Einen Schaltplan habe ich "nur" im Ascii-Format erstellt (ist auch in
der readme.txt enthalten):
Außerdem vllt. ganz praktisch für manche: Es sind Libraries zur
Initialisierung des STM8 sowie für GPIO Behandlung und serielle
Schnittstelle im "Paket" enthalten.
Vielleicht hat ja jemand Spaß damit!
Gruß Ralph
PS: :-) die Anführungszeichen nicht übersehen, das ganze war ein
Spaßprojekt aber irgendwie wars lustig und nun versuche ich etwas in der
Art für einen STM32F103 zu machen (nur in etwas besser und mit mehr
Möglichkeiten)
Tolles Projekt!
Wenn jetzt noch der Funktionsumfang von Micromite [1] auf dem STM32
erreicht wird, dann finden sich sicherlich auch einige ernsthafte
Nutzer.
[1] http://geoffg.net/MicromiteMX170.html
Joe G. schrieb:> Wenn jetzt noch der Funktionsumfang von Micromite [1] auf dem STM32> erreicht wird
... den gibts schon für einen STM32F746
Allerdings ist mir dieser Controller dann für meinen Gebrauch eine
Nummer zu groß, zur Verfügung hab ich hier nur
-F030 (16k)
-L050 (64k)
-F103 (mit 64k und 128k)
-F401
-F429
Ich versuch mich gerade am F030, aber der ist mit seinen 16k schon sehr
dünn bestückt, mal sehen ob das mit dem L050 oder F103 was wird. Das
soll ja ein Spaßprojekt sein und außerdem soll das noch von Hand auf
eine Platine gelötet werden können, bei den Cortex M4 kann ich das nicht
und bin immer auf Boards angewiesen (und deswegen mag ich sie im
Normalgebrauch nicht, auch wenn das, was die Dinger können absolut irre
ist)
Moin,
nett!
Ralph S. schrieb:> Im Zip-Archiv sind sämtliche Dateien enthalten, um die Firmware zu
Fast. st8readihx ist nur als 32-bit Linux-Binary enthalten. Das mag
nicht auf meinem 64-bittigen Linux. Kannst du davon noch den Quelltext
dazutun? Ich nehme an, das macht nicht viel.
Auch sonst hättest du IMHO die Binaries von picocom und stm8flash aus
dem ZIP-Archiv weglassen können. Das sind ja Standard-Tools.
Ich spiele gerade mit einem STM32F103 Mini-Board herum. Das würde sich
vermutlich auch gut für das BASIC eignen. Es hat mehr Pins und der µC
kann direkt USB. Wenn ich mal ein bißchen Muße hab, gehe ich das
vielleicht an :)
Hier ein kleiner unschöner Port auf den stm32f030f4.
load und save hab ich rauskommentiert und sonst einfach nur gpio und
usart geändert. Scheint zu tun, hat aber noch viel optimierungspotential
Das Schöne ist, dadurch dass die stm32's einen integrierten Bootloader
haben, kann man sich den ST-Link sparen.
Wenn man jetzt noch sich noch statt tssop16 breakout boards für den
ch430g, tssop20 breakout boards für beide kaufen, beim ch430g einfach
absägt, kann man jetzt 10 breakout boards und 10 stm32f030f4 kaufen und
man hat 9 Basiccomputer für nahzu den selben Preis wie die zwei auf dem
stm8 basierten.
Man hat leider eben nicht so ein schönes Board.
(Quarz wird auch nicht mehr benötigt)
> "Für die einen ist es ein Microcontroller, für die anderen der> wahrscheinlich billigste BASIC-Computer der Welt">> Mein Basiccomputer läuft in einem STM8S103 Minimumboard aus China (2> Stück für 1,53):
Nett und ich Gratuliere zum Erfolg!
Jedoch: genau so billig kam mir BASIC schon vor über 3X Jahre vor, das
war am Anfang meiner Pubertät...
Axel S. schrieb:> Fast. st8readihx ist nur als 32-bit Linux-Binary enthalten. Das mag> nicht auf meinem 64-bittigen Linux. Kannst du davon noch den Quelltext> dazutun? Ich nehme an, das macht nicht viel.
... ist hier angehängt, aber das Programm hätte dennoch übersetzt werden
können, nur die "Statusanzeige" wieviel Speicher im Flash belegt wird,
wird dann durch eine "Fehlermeldung" ersetzt.
Übersetzen von st8readihx.c mit:
1
gcc st8readihx.c -Os -o st8readihx
Axel S. schrieb:> Auch sonst hättest du IMHO die Binaries von picocom und stm8flash aus> dem ZIP-Archiv weglassen können.
... dem PicoCom hab ich halt mein "Retrogrün" gegeben wie das bei
uralten Terminals der Fall war... und eine Anzeige dafür mit welchen
Parametern das gestartet ist.
Axel S. schrieb:> Das mag> nicht auf meinem 64-bittigen Linux.
Ich sollte es mir zur Gewohnheit machen, Dinge entweder nur als Source
oder in beiden Varianten , 32 und 64 Bit, zugänglich zu machen.
David Sawatzke schrieb:> Hier ein kleiner unschöner Port auf den stm32f030f4.
Schmunzeln muss, auf dem f030 hatte ich das schon und habe das für den
STM8 abgespeckt.
Mir gefällt es grundsätzlich nicht so recht, weil ich etwas mit
Stringvariablen und und Gleitkommazahlen haben mag.
Auf dem F030 hatte ich zuerst den Speicherbereich von 14k bis 16k
reserviert und dann im eigenen Flash das Programm abgelegt. Aber erstens
ist der Flash nicht sooooo oft beschreibbar (lt. Datenblatt nur 1000
mal) und zweitens hab ich dann weitere SCALL Funktionen hinzugefügt
gehabt. Dafür hab ich dem Dingelchen ein 24C128 EEProm, Anschluss für
N5510 84x48 oder SSD1306 Display und einen PCF8574 I/O Baustein
spendiert.
Und muss feststellen, ich hätte das ganze gerne besser in einem größeren
STM32 (bin ich am Überlegen ob ich so viel Zeit opfern mag, das hier war
ja ein kleiner Wettbewerb)
David Sawatzke schrieb:> man hat 9 Basiccomputer für nahzu den selben Preis wie die zwei auf dem> stm8 basierten.
... die Sachen hab ich ja nicht extra gekauft, die hab ich eh hier (STM8
und STM32f030 auch als blanke Chips). Ich versuch mich mal just for fun
an einer Platine (die über Toner-Transfer gemacht sein soll). Werde ich
sehen ob das mit TSSOP20 noch machbar ist.
nach BASIC fängt das Leben an schrieb:> Jedoch: genau so billig kam mir BASIC schon vor über 3X Jahre vor, das> war am Anfang meiner Pubertät...
Ich auch ... aber nostalgische Dinge ohne wirklichen Nutzen sind
manchmal einfach herrlich.
Ich würde gerne wissen, ob es notwendig ist, einen Bootloader zu
installieren, obwohl ich denke, dass das Kompilieren nicht die Option
-flto enthält, da es den glücklichen Fehler gibt ....
... ich verstehe die Frage nicht so wirklich! Ich habe zwar einen
Bootloader für den STM8S103 geschrieben, aber das "Basic-Projekt" darf
diesen explizit nicht installiert haben, da der Flash-Speicher extrem
knapp ist.
Was man machen könnte wäre, einen I/O Pin beim Start abzufragen und je
nach dem welcher Pegel dieser führt, das abgelegte Basic-Programm
automatisch zu starten.
Verzeih mir mein Deutsch ist nicht gut :)
- Das Projekt stm8 und stm32 brauchen Loader?
- Muss Glas verwendet werden?
Vielen Dank im Voraus ist meine erste Inkunition in der Welt von STM,
ich komme von Arduino und ich möchte diesen Code migrieren
https://github.com/monsonite/SIMPL/blob/master/SIMPLEX_2_MSP430FR2433_14.c
The linked project has nothing to do with the basic-interpreter here. If
you want to migrate the linked project you should have to learn how to
work with microcontrollers and how to flash the devices.
STM8 have nothing to do with STM32 (8-Bit vs. 32-Bit). For a short
reading of the linked project, the sources would compile to STM32 MCU'S
so you have to learn how to flash the device.
Perhaps you've get a STM32F103 Bluepill: search the internet how to
flash it !
Hallo, könnten Sie eine Änderung vornehmen, um einen geerdeten Eingangspin für die Autorun-Funktion zu verwenden?
Könnte mir jemand helfen?
Danke schön!
Ach herjeh, nach 6 Jahren eine Anfrage. Grundsätzlich müßte das machbar sein, wenn man einen GPIO der mittels IN/OUT gesteuert wird vom Interpreter entfernt und diesen für einen Autorun-Pin verwendet.
Allerdings weiß ich noch, dass der Flashspeicherplatz extrem ausgereizt war und ich nicht weiß, ob das im Code noch unterbringbar ist.
um einen geerdeten
Eingangspin für die Autorun-Funktion zu verwenden
Hier ist wohl ein Eingangspin gemeint, der bei Anliegen eines 0 Signals (Pin auf Masse) das gespeicherte Programm starten soll, oder?
Soll der Chip mit dem Interpreter tatsächlich in einer Schaltung so eingesetzt werden ist vllt. grundsätzlich zu überlegen, ob ein anderer Chip hierfür nicht besser eingesetzt werden kann, da der STM8S103 wohl EOL ist.
Tut mir leid, aber ich habe Ihr Projekt erst jetzt gesehen, deshalb schreibe ich Ihnen jetzt. Wenn es möglich wäre, wäre das natürlich eine schöne Sache. Ich habe versucht, den Code ein wenig zu verstehen, aber ich habe nicht viel Erfahrung damit SDCC, also suche ich nach Möglichkeit Hilfe, ich würde mich für diese Schaltung interessieren, wenn sie machbar ist.
Danke .
... sodele, jetzt habe ich mich doch hingesetzt und den Interpreter überarbeitet und an die Gegebenheiten die ich in meinem Setup seither geändert habe angepasst.
Das ganze ist im Anhang verfügbar und ein Autostartpin ist mit PA1 gegeben: Eine logische 0 (Verbindung zu GND) wird ein im EEProm gespeichertes Programm automatisch starten.
Die bisherige Funktion SCALL heißt jetzt FUNC und das ganze wurde so zusammengequetscht, dass es noch eine zweite Funktion bei FUNC gibt: Ausgabe eines gesamten Bytes auf den I/O Pins 0 bis 8.
Programme und Quellen sowie Dokumentation und einen Ascii-Schaltplan sind im Anhang.
Sollte tatsächlich der Bedarf nach einem minimalistischen Basic-Interpreter bestehen, der dann noch preiswerter als STM8S103 ist (8€ für 10 Stck), kann ich die Funktionalität auch in einem STM32F030 im 20 pol. TSSOP machen (der dann 6€ für 10 Stck. kostet) und zum einen schneller läuft, Erweiterungen noch möglich sind (weil größerer Flashspeicher) und auch für das Basicprogramm mehr Platz zur Verfügung hat...
Hrmpf, eigentlich wollte ich ja meine "Spielesammlung" in einem STM32F4 weiter betreiben, aber man lässt sich ja so leicht ablenken (hat aber dennoch Spaß gemacht).
@Camusso: wenn Du das wirklich verwenden magst => viel Spaß damit !
HALLO! Was für eine Überraschung, dass Sie mir heute eine große Hilfe geleistet haben. Ich werde die Funktion des neuen Interpreters ausprobieren. Natürlich hätte ich auch gerne einen anderen Interpreter für ST32F4, noch günstiger, danke für Ihre Arbeit! Wenn ich etwas schulde, sagen Sie mir, dass ich einen Beitrag leisten werde.
Frohe Weihnachten!
Hallo, ich habe mir das ganze Projekt angesehen, aber leider habe ich die Datei tbasic.ihx zum Laden in den Mikrocontroller nicht gefunden, ich bin nicht sehr kompetent im Kompilieren, ich habe die Windows-Version und kenne die richtige nicht Kompilierungssyntax, wenn Sie mir helfen oder mir die .ihx-Datei senden können.
Tausend Dank!
ich habe die
Windows-Version und kenne die richtige nicht Kompilierungssyntax, wenn
Sie mir helfen oder mir die .ihx-Datei senden können.
Das Projekt besteht aus mehr als nur der Datei tbasic.c. Deshalb ist das ganze ein der Verzeichnisstruktur gemacht, wie es gemacht ist. tbasic.c benötigt noch andere Dateien, die übersetzt und dann zu einem Programm zusammen gelinkt wird.
Die gesamten Abläufe, wie das kompiliert und gelinkt wird sind in einem sogenannten Makefile zusammengefasst. Das Makefile wird von einem Programm namens "make" aufgerufen. Standardmäßig ist dieses jedoch bei Windows nicht installiert.
Sobald Programme einen gewissen Umfang über ein einfaches Blinkprogramm hinaus geht, ist es normal, dass ein Gesamtprojekt aus mehreren Quelldateien besteht.
Hier sind es die Dateien:
1
include --------- stm8s.h
2
stm8_init.h
3
stm8_gpio.h
4
stm8_systimer.h
5
6
src ------------- stm8_systimer.c
7
stm8_init
Ein Compilergang für eine einzelne Datei reicht hier natürlich nicht aus. Du solltest Dich von daher bei C (oder auch C++) mit grundlegenden Dingen wie Compiler, Linker und Präprozessor auseinandersetzen (so Du denn in C / C++ programmieren magst).
Wie dem auch sei, hänge ich hier die compilierte tbasic.ihx mit an.
Ich hoffe, dass Du unter Windwos eine serielle Verbindung zum Interpreter hinbekommst, das Protokoll der Verbindung ist:
19200 bd
1 Startbit
8 Datenbits
1 Stopbit
keine Parität
Sollte tatsächlich der Bedarf nach einem minimalistischen
Basic-Interpreter bestehen, der dann noch preiswerter als STM8S103 ist
(8€ für 10 Stck)
Du könntest Dir den CH32V003 ansehen. Das ist ein RISC-V-Controller, der mit 2 kiB RAM und 16 kiB Flash daherkommt und mit bis zu 48 MHz Takt betrieben werden kann. Den gibts im 20poligen Gehäuse (TSSOP und QFN), aber auch im 16- oder nur 8-poligen Gehäuse (SO-16 & SO-8), was für viele einfacher zu löten ist.
Die Peripherie ist sehr nah an der Peripherie der kleinen ARMe von STM orentiert. Praktisch ist, daß man den CH32V003 auch mit 5V betreiben kann, was viele Probleme mit Pegelwandlern & Co. vermeiden hilft.
Programmierung erfolgt über eine einzelne Leitung.
Und den CH32V003 gibt es im 50er-Pack für 13.70 EUR incl. Versand.
Nochmals vielen Dank, dass Sie mir die kompilierte Datei geschickt haben. Ich bin neugierig auf diesen neuen CH32V003. Er ist wirklich günstig. Es wäre sehr schön, auch einen speziellen Basisinterpreter dafür zu haben, um eine Alternative für einen kleinen Minimalcomputer mit der Basisversion zu haben.
Vielen Dank, ich werde die Entwicklung des Projekts mit großem Interesse verfolgen.
Von diesem Controller habe ich schon gelesen, aber ich werde da wohl nicht darauf einsteigen. Zum einen habe ich schon wirklich genügend Plattformen für Mikrocontroller, zum anderen habe ich schon satt gekämpft mit dem Bootloader des CH552 von WCH bis das funktioniert hat (ohne das zu benötigen, MCS-51 werde ich wohl nur bei wiederaufleben noch historischer Projekte verwenden) und zum anderen braucht es dann wieder eben das notwendige Programmierinterface. Außerdem kaufe ich bei Aliexpress nichts, weil dort immer eine Kreditkarte verlangt wird und ich mich bis in mein hohes Alter hinein bis heute erfolgreich gegen eine Kreditkarte gewehrt habe.
Außerdem kaufe ich bei
Aliexpress nichts, weil dort immer eine Kreditkarte verlangt wird und
ich mich bis in mein hohes Alter hinein bis heute erfolgreich gegen eine
Kreditkarte gewehrt habe.
Ach? Die nehmen auch PayPal. Funktioniert. Ohne Kreditkarte.
Auch muss man die Teile nicht über Aliexpress kaufen, die gibts natürlich auch bei LCSC.
Von diesem Controller habe ich schon gelesen, aber ich werde da wohl
nicht darauf einsteigen. Zum einen habe ich schon wirklich genügend
Plattformen für Mikrocontroller, zum anderen habe ich schon satt
gekämpft mit dem Bootloader des CH552 von WCH bis das funktioniert hat
(ohne das zu benötigen, MCS-51 werde ich wohl nur bei wiederaufleben
noch historischer Projekte verwenden) und zum anderen braucht es dann
wieder eben das notwendige Programmierinterface. Außerdem kaufe ich bei
Aliexpress nichts, weil dort immer eine Kreditkarte verlangt wird und
ich mich bis in mein hohes Alter hinein bis heute erfolgreich gegen eine
Kreditkarte gewehrt habe.
Wenn Dich der Controller interessiert, besorge ich Dir gern die empfohlene Ausstattung. Meld Dich einfach per PM bei mir.
Hallo, ich habe mehrmals bei Aliexpress gekauft, zum Beispiel das in diesem Projekt verwendete stm8s103, 100 Stück für nur 77 Euro, ich würde sagen, ein sehr vorteilhafter Preis...
100 Stück für nur 77 Euro, ich würde
sagen, ein sehr vorteilhafter Preis...
Da sind 13.70 Euro (incl. Versand und Einfuhrumsatzsteuer) für 50 Stück des CH32V003 irgendwie nicht weniger vorteilhaft.
Doppelt so viel RAM, doppelt so viel Flash, dreifache Taktfrequenz ...
Wobei man das sicher nicht direkt vergleichen kann; ein 8-Bit-µC verwendet recht sicher kompakteren Code als ein 32-Bit-RISC-µC, auch wenn der mit 16-Bit-Instruktionen ("gepackt", also analog zu ARM-Thumb) arbeitet.
Und da die Peripherie sich gar nicht so irrwitzig von der des STM8S103 zu unterscheiden scheint, ist eine Portierung des Projektes vermutlich gar nicht so ein großer Aufriss - denn das ist ja wohl in C geschrieben.
Ja, tatsächlich ist es draußen kalt und ich nutze diese Gelegenheit, um mit neuen Basisinterpretern auf Mikrocontrollern zu experimentieren, auch mit Hilfe Ihrer Gruppe, die mir gute Ratschläge gibt, vielen Dank!
Der CH32V003F4P6 ist als direkter Ersatz für den STM8Sx03F3P6 gedacht.
Hab ich auch schon erfolgreich ausprobiert.
Ganz lieben Dank!
Ich habe mir gestern den Chip per Datenblatt und Internetrechereche angesehen und für mich entschieden, dass ich den nicht machen werde. Ich werkle unter Linux und hätte einen sehr großen Aufwand, dass an meine bevorzugte Arbeitsweise (alle Projekte mittels Makefile und als Editor Geany oder Konsoleneditor) einzurichten.
Ich verzettele mich immer viel zu sehr (auch gerade wieder, weil ich den Interpreter jetzt auch für den STM32F030 "komplett" gemacht habe). Momentan wollte ich ja meine Spielesammlung für F401 bearbeiten und habe nun 3 Tage lang am Interpreter gewerkelt, einfach weil das Spaß gemacht hat.
Deswegen werde ich diesen Chip vorerst einmal nicht anfassen, aber vielen Dank noch einmal.
So, hier jetzt auch die überarbeitete Version für einen STM32F030. Ich hatte kurz überlegt, hierfür einen neuen Thread aufzumachen, weil das ja ein ganz anderer Chip als der im Eröffnungsthread von vor 6 Jahren beschrieben ist, aber der Kern des Interpreters ist der selbe von daher.
Die Schaltung ist dafür ausgelegt, die Firmware des Chips mittels des integrierten Bootloaders des F030 zu flashen. Da das ganze minimalistisch bleiben sollte, wird der Bootloader mittels zweier Tasten (Boot0 und Reset) aktiviert (genauso, wie das die BlackPill und die BluePill - hier mittels 2 Jumper - auch machen).
Der Interpreter belegt mit dem von mir verwendeten Compiler eine Größe von 13896 Bytes. Ich hoffe dass die Dateigröße mit neueren als den von mir verwendeten arm-none-eabi-gcc Version 6 nicht beim compilieren zunimmt. Größer als 14336 Bytes darf es nicht sein, da sonst der Flashbereich beschrieben wird, der im Flash zum Speichern eines Basicprogramms dient (ab Adresse 0x80003800).
Im Vergleich zu der Version mit dem STM8 kann dieser Interpreter nun:
für ein Basicprogramm 2048 tokenisierte Bytes (anstelle von 512) speichern
DELAY Funktion
ADC Funktion zum Einlesen eines analogen Wertes
BYTEOUT zum Ausgeben eines kompletten 8-Bit Wertes auf 8 Pins I/O 0 bis 7
11 I/O Pins von denen einer als analoger Eingang dienen kann.
Wie zuvor hat auch der Interpreter einen Autorunanschluß mit dem ein gespeichertes Programm sofort nach anlegen der Betriebsspannung gestartet werden kann, so dieser auf GND gelegt ist.
Wer das brauchen kann: Viel Spaß damit, :-) ich habe glaube ich damit genug gespielt. Ich wollte noch eine Funktion integrieren, mit der man ein 74HC595 Schieberegister als Porterweiterung hätte bedienen können, aber ich habe das nicht mehr hineingequetscht bekommen.
So nebenbei braucht diese Variante des Interpreters auch keinen zusätzlichen Programmer um ihn zu flashen, ein USB zu (TTL)RS232 Adapter wie im Schaltplan genügt um damit werkeln zu können.
Ich
werkle unter Linux und hätte einen sehr großen Aufwand, dass an meine
bevorzugte Arbeitsweise (alle Projekte mittels Makefile und als Editor
Geany oder Konsoleneditor) einzurichten.
Hmm. Man muss nicht "mounriver" verwenden; hast Du das hier nicht gesehen?
HALLO ,
Das neue TinyBasic für STM32F030F4P6 funktioniert gut! Ich habe die Firmware mit STM32CUBE und STLINK geladen, dann habe ich die serielle Schnittstelle mit TERATERM verbunden und alles funktioniert einwandfrei!! . Danke für dieses neue TinyBasic!
Gerne verfolge ich die Entwicklung weiterer Neuigkeiten.
Fröhliche Weihnachten an alle!
Gerne verfolge ich die Entwicklung weiterer Neuigkeiten.
Ich glaube nicht, dass ich daran noch weiter etwas entwickeln werde, zumindest nicht auf der Basis dieses TinyBasic. Es ist einfach zu rudimentär, ist sehr eingeschränkt, keine freie Wahl der Variablennamen, kein DIM und vor allem keine Gleitkommazahlen.
Sollte ich mich noch einmal an ein Basic machen (SOLLTE), wird das eher was ganz anderes werden !
Ja, aber für kleine Automatisierungen ist es ideal :), aber wenn Sie eines Tages etwas Fortgeschritteneres entwickeln, wird es noch besser sein, trotzdem vielen Dank für Ihre Unterstützung und ein frohes neues Jahr!
Ach herjeh, nach 6 Jahren eine Anfrage. Grundsätzlich müßte das machbar
sein, wenn man einen GPIO der mittels IN/OUT gesteuert wird vom
Interpreter entfernt und diesen für einen Autorun-Pin verwendet.
Allerdings weiß ich noch, dass der Flashspeicherplatz extrem ausgereizt
war und ich nicht weiß, ob das im Code noch unterbringbar ist.
In den 6 Jahren gab es aber auch Fortschritte bei SDCC, so dass das, bei dem, was einst "Flashspeicherplatz extrem ausgereizt", nun noch Luft sein könnte.
In den 6 Jahren gab es aber auch Fortschritte bei SDCC, so dass das, bei
dem, was einst "Flashspeicherplatz extrem ausgereizt", nun noch Luft
sein könnte.
:-) mittlerweile habe sogar ich (und ich brauche lange bis ich neue Versionen verwende) einen neueren SDCC installiert. Wirklich "Luft" was den Speicherplatz angeht hat das nicht gebracht.
Für Camusso's "Autorun-Pin" nach anlegen der Spannung hats allerdings noch gereicht gehabt. Grundsätzlich hätte ich da noch ein paar Ideen gehabt, was mit der "func(Funktionsnr, Value)" noch hätte anstellen können. Als erstes wäre mir hier ein Portexpander mit 74HC595 eingefallen. Dafür hat es dann allerdings nicht gereicht.
Außerdem werde ich für den STM8 nicht mehr wirklich etwas machen, weil mir vor ca. einem halben Jahr jemand angezeigt hat, dass ST die STM8-Serie auf NRND (not recommended for new designs) gesetzt hat und die Serie wohl irgendwann auslaufen wird. Zudem war der STM8 vor der Pandemie ein absolut billiges Spielzeug auf dem Niveau eines ATmega (aus meiner Sicht der Dinge). Da hatte der irgendwas zwischen 20 und 25 ct gekostet.
Jetzt ist mein billiges Spielzeug für den SDCC noch die PDK Familie von Padauk. Hier an dieser Stelle ein herzliches Dankeschön an Philipp (und das Team rund um den SDCC) dass ihr da immer wieder etwas daran werkelt (auch wenn ich bei der Version 4.3 wirkliche Probleme hatte den in meiner selbstgestrickten Live-Linux-Version rund um Porteus / Slackware an's Laufen zu bekommen).
Also: :-) Dankeschön, dass es den SDCC gibt ! (genauso gemeint)
In den 6 Jahren gab es aber auch Fortschritte bei SDCC, so dass das, bei
dem, was einst "Flashspeicherplatz extrem ausgereizt", nun noch Luft
sein könnte.
:-) mittlerweile habe sogar ich (und ich brauche lange bis ich neue
Versionen verwende) einen neueren SDCC installiert. Wirklich "Luft" was
den Speicherplatz angeht hat das nicht gebracht.
Dann bliebe noch:
--opt-code-size verwenden (falls da nicht eh schon geschieht
--max-allocs-per-node N (bei größerem N wird stärker optimiert, aber das Kompilieren dauert länger und verwendet mehr RAM, aber wenn du in den 6 Jahren Zugang zu einem schnelleren Rechner mit mehr RAM erhalten hast, sollte das gehen).
mir gefällt das Projekt, auch wenn es kaum praktische Anwendungen geben dürfte.
Aber das Problem möglichst viel in so einen kleinen STM8 rein zu bekommen
hat mir keine Ruhe glassen.
Ich habe den Code etwas geändert und bin aktuell bei einer Auslastung von ca. 93%.
Habe aber auch einige neue Funktionen eingebaut:
AND, OR, XOR, ADC, DELAY, BYTEOUT, PEEK, POKE, EEPROM, <>
Die größten Änderungen um Platz zu sparen:
doppelten Code in separate Funktionen packen
Function Pointer Arrays statt der großen switch Anweisungen
Leider ist mein STM8 Board noch nicht da,
ich kann noch nicht testen.
Hallo Andrea,
Ich bin sehr an Ihrer Modifikation interessiert, ich würde sie gerne ausprobieren, wenn Sie mir die .ihx-Datei schicken könnten, wenn Sie möchten, schicke ich Ihnen ein STM8-Board, ich habe viele.
Lass es mich wissen .
Danke schön!
Ich habe den Code etwas geändert und bin aktuell bei einer Auslastung
von ca. 93%.
Habe aber auch einige neue Funktionen eingebaut:
AND, OR, XOR, ADC, DELAY, BYTEOUT, PEEK, POKE, EEPROM, <>
... freu ich mich, wenn andere solche Basteleien auch mögen (auch dann wenn es wohl kaum Anwendungen gitbt).
DELAY, BYTEOUT und ADC hab ich ja in meiner STM32F Version implementiert gehabt (im STM8 nicht). Die letzte Compilierung mit STM8 ergab:
1
Device : stm8s103f3 / Flashsize: 8192 bytes
2
Program : at address 0x8000 7421 Bytes (90.6% full)
Hätte ich jetzt wahrscheinlich auch noch etwas Platz zum Basteln. Allerdings muss ich sagen, dass ich mit meinem Bootloader aus
verwende und der benötigt in sich auch Speicherplatz, so dass bei mir für das Anwenderprogramm dann 7744 anstelle von 8192 Bytes zur Verfügung stehen.
Außerdem denke ich, dass wenn ich an dem Basic vor lauter Lust und Dollerei noch einmal etwas mache, wird es die STM32F Variante sein.
Ich finds aber klasse wenn du dich damit beschäftigst und bin gepsannt darauf, wie deine erweiterte Version ausschaut.
Hallo zusammen, ich verfolge gespannt die Lösung, neue Anweisungen zum stm8s103f3p6 hinzuzufügen. Ich habe auch eine neue Idee. Ich hoffe, dass Sie, die mehr Experten als ich sind, mir helfen können. Ich habe ein Foto eingefügt, damit Sie das verstehen, indem ich ein externes Bild einfüge 24lc64 EEPROM, Sie könnten 8 KB für das Programm haben!
und nutzen Sie die internen 512 Byte als Datenspeicher.
Es kann getan werden?
Danke !
@Camusso N
ich poste die .ihx Datei sobald ich mein Board habe und alles testen kann.
Danke! Aber das Board allein nützt mir nichts, ich hat auch den Programmer
und das seriell Interface bestellt.
Mein Board soll bis zum 12.1. ankommen.
@Ralph S
Danke für das schöne Projekt!
Ich hänge einfach mal meinen aktuellen Stand an.
Ich habe das aber bisher nur auf Windows und einen ESP32 laufen lassen.
Alles was ADC, EEPROM, PEEK, POKE, usw. betrifft ist noch völlig ungetestet.
Das makefile habe ich für Windows erweitert.
Ich benutze den SDCC 4.3.0.
Hallo Andreas,
Vielen Dank, dass Sie einen Teil der Dateien bereits veröffentlicht haben. Ich werde versuchen, sie zu studieren, um mehr zu erfahren. Wenn Sie dann die Hex-Datei haben, wird es noch besser.
Hat Ihnen meine Idee gefallen, den Speicher mit einem externen Eeprom zu verwalten?
Auf Wiedersehen!
Hallo Andreas,
Vielen Dank, dass Sie einen Teil der Dateien bereits veröffentlicht
haben. Ich werde versuchen, sie zu studieren, um mehr zu erfahren. Wenn
Sie dann die Hex-Datei haben, wird es noch besser.
Hat Ihnen meine Idee gefallen, den Speicher mit einem externen Eeprom zu
verwalten?
Auf Wiedersehen!
Roberto.
Na ja, ein EEPROM als externen Speicher zu verwenden ist nicht wirklich eine IDEE, sondern die Norm. Die Idee war eher, genau den internen und nicht einen externen EEProm zu verwenden. Es hat eben eine Ein-Chiplösung sein sollen. Wenn schon ein externes EEProm, dann eher doch ein 24LC256, der ist 4 mal so groß und zumindest bei LCSC.COM deutlich preiswerter.
Hmmmmmmmmmm, eigentlich (und nicht nur eigentlich) muß man nur die Funktionen:
eeprom_unlock
eeprom_read
eeprom_write
gegen Funktionen austauschen, die dann eben ein EEProm ansprechen. @Roberto, kann es sein, dass du nicht so wirklich viel Ahnung von C (und nicht nur vom STM8 nicht) hast ?
Für den I2C Bus des EEProms würde ich zumindest in Verbindung mit dem STM8 eher 2,2kOhm verwenden (das hatte bisher bei mir problemlos geklappt gehabt).
Alles was ADC, EEPROM, PEEK, POKE, usw. betrifft ist noch völlig
ungetestet.
:-) das ist dann aber irgendwie noch keine Version für STM8! Auf einem STM32 konnte ich auch deutlich mehr, hatte auch ByteOut, ADC auch. Bei Peek und Poke hängts ja davon ab, was du hinter den anzusprechenden Adressen verstecken magst. Ich hatte das lieber über "func" gelöst. Bei dem STM32 kannst du dich dann absolut austoben. Ich weiß, dass das sogar auf einem F4 läuft, aber das ist dann irgendwie doch zu arg einen schönen M4 Controller mit einem sehr kastrierten Basic zu betreiben, allerdings: gehen würde es.
Wenn du mit dem Basic hier gerne weiter machen magst, :-) gerne! Grundsätzlich ist es dann halt aber so, dass das nicht zweigleisig geschehen sollte (bspw. umd die Wünsche von Roberto zu erfüllen und das um ein EEProm zu erweitern und dann den frei werdenden Flashspeicher zu nutzen). Hier kann es dann sogar reichen, eine kleine Verwaltung zum EEPromspeicher zu machen, um dann mehr als nur ein Programm speichern zu können, ein 24LC256 hätte immerhin 32kByte Speicher.
Aber wie gesagt, so etwas würde ich dann lieber auf einem anderen Controller machen. Abgesehen davon ist die (hier dann wirklich bessere) Scriptsprache doch tatsächlich Python. Mikropython läuft auf einem STM32F4xxx recht gut. Deswegen stellt sich ehrlicherweise die Frage nach dem Sinn von Basic.
Als "Spielzeug" war das witzig. Wie gesagt, du kannst dir das hier gerne zu eigen machen! Grundsätzlich, egal was du machst (wenn ich mir hier die vielen negativen Bewertungen ansehe) wünsche ich dir viel Spaß dabei.
Aber wie gesagt, so etwas würde ich dann lieber auf einem anderen
Controller machen. Abgesehen davon ist die (hier dann wirklich bessere)
Scriptsprache doch tatsächlich Python. Mikropython läuft auf einem
STM32F4xxx recht gut. Deswegen stellt sich ehrlicherweise die Frage nach
dem Sinn von Basic.
ich glaub da hast Du Recht, BASIC auf dem STM8 macht wirklich nicht viel Sinn.
Wie gesagt, du kannst dir das hier gerne
zu eigen machen!
Hallo Ralph und Andreas, vielen Dank, denn ihr berät mich immer gut, ihr seid Experten in C und stm8, leider habe ich immer nur Pic und 8051 verwendet, daher habe ich insbesondere im Programmieren in C keine Erfahrung, weshalb ich euch gefragt habe für die Dateien .ihx, wenn Sie mir helfen könnten, weil ich tagelang versucht habe, die Dateien mit einem Ubuntu-PC zu kompilieren, aber es gelingt mir nicht, insbesondere mit dem Befehl „make“. Ich bin sehr unerfahren und verwende fast nur Basic- und MPASM-Mikrochips.
weil ich tagelang versucht habe, die Dateien mit
einem Ubuntu-PC zu kompilieren, aber es gelingt mir nicht, insbesondere
mit dem Befehl „make“.
Das... verstehe ich nun allerdings überhaupt nicht! Wenn du das Zipfile in einen Ordner deiner Wahl entpackt hast, in der Konsole in dieses Verzeichnis wechselst und dort eingibst:
make
Dann hätte bei einem installierten SDCC das allerdings kompilieren müssen !
HALLO ! Ich habe es endlich geschafft, die tbasic-Datei zu verstehen und zu kompilieren, aber die letzte, die Sie gepostet haben, weist einen Fehler auf. Ich füge ein Foto von der Datei bei, die mir mein SDCC gibt.
Tausend Dank!
Übrigens kann man den Text, der in dem Konsolenfenster da steht, auch markieren und in die Zwischenablage kopieren, und somit hier auch als Text einfügen, dazu muss man keine Kamera in die Hand nehmen und ein Photo vom Monitor anfertigen.
Hallo, Sie haben versucht, den Code in Zeile 1581 zu analysieren, der Fehler in zu vielen Parametern, ich habe versucht, ihn zu ändern, aber ich verstehe es nicht, leider interessiere ich mich seit kurzem für C und bin sehr schlecht vorbereitet ... ...
Ich akzeptiere jedoch Ihren wertvollen Rat und werde weiterhin C lernen. Ich wünsche Ihnen einen schönen Sonntag
Der letzte Post war von Andreas. Wäre sein Setup fehlerfrei, hätte er auch eine *.ihx Datei erzeugen müssen. Hmmmm, ich werde mir das von Anfreas morgen mal genauer ansehen, aber eigentlich ist es ungeschickt, wenn es 2 Weiterentwicklungen gibt, zudem noch unter Linux und Windows. Hier wäre es geschickter, eine Version zu haben, die unter Linux und Windows korrekt compiliert. Der Fehler mit unterschiedlicher Parameteranzahl sollte aber auffindbar sein. Schwieriger wird es, wenn man auf eine nicht vorhandene Hardware zugreift. Hier ist man dann nicht sicher, ob bspw. der ADC richtig funktioniert.
So, den Code von Andreas habe ich mir nicht angesehen (weil ich bei meinem eigenen bleiben möchte).
Aaaaber ich habe da mal etwas (zum Lernen) vorbereitet und der Anhang hier ist ziemlich groß (nicht ganz 8 MByte).
Sollte das zu groß sein, so mag mir ein Admin auf die Finger klopfen und ich werde das dann nicht wieder tun.
Im Anhang ist ein komplettes Setup für den STM8 des SDCC-Compilers für ein 64-Bit Linux enthalten (allerdings "nur" SDCC v4.1.0). Damit der Anhang nicht zu groß ist, wurden alle nicht STM8 Sachen des Compilers weggelassen (hier gibt es dann die Frage an Philipp Klaus K. ob man das überhaupt darf, den SDCC zu "kastrieren").
Das Setup ist irgendwie "Arduino-Style", das heißt: alle vom Compiler benötigten Dateien (inkl. stm8.lib) sind über relative Verzeichnisangaben gemacht und die im Setup enthaltenen Beispielsverzeichnisse bedienen sich hieraus. Das heißt, dass der Compiler und Linker auch nur aus diesem Verzeichnis "stm8" erreichbar ist.
In allen Beispielsverzeichnissen können die Beispiele mit einem einfachen Aufruf "make" übersetzt werden.
Um mit dem Setup "spielen" zu können sind im Stammverzeichnis stm8 2 TUI-Mode-Programme enthalten:
genmakef
cide
Mit den beiden Programmen sollte fürs erste ein Einstieg und Arbeiten mit C und STM8 auf der Konsole möglich sein.
genmakef im Stammverzeichnis stm8 mittels:
./genmakef
starten. Hier kann nun ein Projektverzeichnis und eine Projektdatei angelegt werden, die dann auch die main-Funktion beinhaltet.
Mit "select path to STM8 projects" im aufgehenden Dialogordner das Verzeichnis stm8 wählen. Mit "Makefile generator" kann hier ein Makefile zusammengeklickt werden. Es sind Angaben zu Projektordner und Projektname zu machen. Es muß der STM8 gewählt werden, für den ein Programm geschrieben werden soll (Auswahl hier nur STM8S003, STM8S103F3, STM8S105K4 und STM8S105K6). Der Programmer sollte als ST-Link SWIM gewählt werden, da der Bootloader eine Eigenkreation von mir ist und auf Deinem System nicht verfügbar ist).
Die wichtigste Eigenschaft ist "Additional source file to link". Hier wird ausgesucht, welche Softwarebibliothek mit eingebunden werden soll und mindestens ./src/stm8_init.c ist auszuwählen (dieses erscheint dann im blauen Fenster als:
SRCS = ../src/stm8_init.rel
Die Endung .rel gibt es deshalb, weil Objektdateien des SDCC so bezeichnet werden, d.h. aus stm8_init.c wird der Compiler stm8_init.rel erzeugen und dieses dann dem späteren Gesamtprogramm hinzufügen.
Wenn die Auswahl getroffen ist, kannst du dir das Verzeichnis mit der C-Projektdatei und das Verzeichnis generieren lassen.
Beende genmakef und wechsle in das von gerade erstellte Verzeichnis mit:
cd ./meinverzeichnis
Hier sollten jetzt 2 Dateien liegen: Die C-Projektdatei und das dazugehörende Makefile.
Um nun damit etwas anfangen zu können, mußt du dein Programm schreiben können. Hierzu startest du die Konsole-IDE cide mittels:
Hallo Ralph, danke für deinen Vorschlag. Jetzt werde ich versuchen, deine Software zu installieren, um zu sehen, ob ich es besser verstehen kann. Ich habe es geschafft, mit dem Befehl „make“ zu kompilieren, aber der Compiler generiert die .ihx-Datei, aber wenn ich sie auf den stm8 lade, geschieht dies Es funktioniert nicht, also denke ich, dass da immer noch ein Fehler meinerseits vorliegt....
Ich verwende STLINK mit dem SWING-Signal und zum Testen eines seriellen USB-Adapters. Mit Ihrer Version funktioniert es gut, aber mit dieser neu kompilierten Version funktioniert es nicht ...
Hallo Ralph, vielen Dank, dass du mir den stm8-Ordner mit den Einstellungen geschickt hast. Mit diesem Ordner kann ich die von dir gepostete Datei tbasic.c korrekt kompilieren, während beim Kompilieren der Datei mit den neuen Verzögerungs-ADC-Funktionen usw. Probleme auftreten.
Ich versuche den Fehler zu finden...
Have fun!
Ich habe einen 10-kb-Trimmer an den ADC-Pin angeschlossen und konnte den Variablenwert lesen!
Byteout , peek , poke , eeprom(32)
Ich kenne die Syntax nichtViel Spaß!
Ich habe einen 10-kb-Trimmer an den ADC-Pin angeschlossen und konnte den Wert der Variablen lesen!
Byteout, Peek, Poke, EEPROM(32)
Ich kenne die Syntax nicht. Haben Sie Vorschläge?
Das ist doch exakt der gleiche Fehler, um den es schon vor einer Woche
ging.
Das ist exakt der gleiche Fehler !!!
Und der Fehler von Roberto ist, dass er unterschiedliche Versionen untereinander mischt (unter Garantie).
In meinem Sourcecode steht in Zeile 1582 kein "delay" und auch kein "delay_ms". Scheinbar jedoch versucht er, die andere (und absolut ungetestete) Version von Andreas mit meinem Makefile zu übersetzen (was dann nicht funktioniert).
In meiner Version gibt es kein Peek, Poke und Byteout!!! Peek und Poke habe ich nie implementiert und Byteout gibt es im STM32F030!
Solange also Roberto grundsätzlich versucht die Datei von Andreas zu übersetzen wird das scheitern oder er muß im C-Source den Fehler von Andreas suchen!
Hallo Ralph, vielen Dank, dass du mir den stm8-Ordner mit den
Einstellungen geschickt hast. Mit diesem Ordner kann ich die von dir
gepostete Datei tbasic.c korrekt kompilieren, während beim Kompilieren
der Datei mit den neuen Verzögerungs-ADC-Funktionen usw. Probleme
auftreten.
Ich versuche den Fehler zu finden...
So, jetzt habe ich heute Nacht doch wieder mit dem Interpreter zugebracht und habe mir die Version von Andreas angesehen.
Er hat doch einige Änderungen vorgenommen, allen vorweg hat er etwas an der Struktur geändert: er verwendet einen Funktionspointer anstelle der switch-case Anordnung.
Hierbei muß ihm ein Fehler unterlaufen sein, denn sein <byteout> produziert beim Aufruf einen Fehler.
Ich habe meiner Version ein <byteout> hinzugefügt, ebenso ein <delay> und ein <adc>.
Doppelten Code wie von ihm beschrieben habe ich nicht bei mir gefunden, die Warnmeldungen habe ich ebenfalls eliminiert und ich habe seine Methode die IO-Pins anzusprechen übernommen. Danach war es 3 Uhr morgens und ich wollte das nicht mehr für hier aufarbeiten.
Die größe Codeeinsparung wurde dadurch erreicht, dass die Initialisierung der seriellen Schnittstelle geändert wurde. Hier kann nicht mehr aus dem laufenden C-Programm heraus die Baudrate geändert werden (wurde nicht genutzt) und ist jetzt fest auf 19200 Baud eingestellt.
Dadurch habe ich erreicht, dass der Code unterhalb von 7744 Byte geblieben ist (um genau 5 Bytes) und ich meinen Bootloader für den STM8 verwenden kann (anstelle eines STLINKv2).
@Roberto: Nachdem ich heute abend dann das hier eingestellt habe, werde ich definitiv nichts mehr an dem Interpreter machen wollen !
Außerdem werde ich für den STM8 nicht mehr wirklich etwas machen, weil
mir vor ca. einem halben Jahr jemand angezeigt hat, dass ST die
STM8-Serie auf NRND (not recommended for new designs) gesetzt hat und
die Serie wohl irgendwann auslaufen wird.
Ja, sehr schade. Sauberes Design, super Datenblätter und Manuals, günstig. Beim ersten Versuch, so einen STM8 in Betrieb zu nehmen ging das auf anhieb gut, das komplette Teil war echt einfach zu verstehen, wenn man schon andere Controller kennt.
Ich hab noch einige hier liegen, die werden noch "verbraten" und dann ist wohl Schluss...
Hallo Ralph, okay, danke, denn du hast mir sehr geholfen und ich fange langsam an, etwas Neues zu lernen!
Vielen Dank auch für die neuesten Änderungen, die Sie veröffentlichen werden.
... so, hier nun meine "finale" Version des TBasic für den STM8. Ich denke nicht, dass ich den noch einmal wirklich anfassen werde, da der Speicherbedarf jetzt bei 7730 Bytes liegt. Ich verwende gerne meinen eigenen Bootloader beim STM8 und hier darf dann - da der Bootloader ebenfalls Speicherplatz benötigt - eine Dateigröße von 7744 Bytes nicht überschritten werden. Von daher ist nun wirklich kein Platz mehr für Erweiterungen.
@Andreas: Solltest du hier noch einmal lesen: Ein Dankeschön für deine Version des TBASIC. Auch wenn ich deine (schicken) Funktionspointer nicht übernommen habe, so hat mir die Lösung des Ansprechens der Portpins über struct und typedef gefallen (auf diese naheliegende Idee bin ich vor 6 Jahren nicht gekommen) und habe diese übernommen.
@Roberto: Die Syntax des Interpreters ist nun etwas ausführlicher geworden und nun in einem (halbwegs) saubereren PDF-File untergebracht. Wenn du dich an die Anleitungen darin hälst, solltest du zum einen keine Probleme mehr haben, so dein SDCC komplett installiert ist, den Interpreter zu übersetzen (wobei das gar nicht notwendig ist, da die .ihx Datei enthalten ist).
Implementierte Programmbefehle sind jetzt:
ABS - ADC - BYTEOUT - DELAY - FOR / NEXT - FUNC - GOSUB / RETURN – IN - IF - INPUT – OUT - PRINT - RND
Kommandobefehle im Terminalmodus:
LIST - LOAD - NEW - SAVE - SIZE - RUN
Und last but not least: Die Autoloadfunktion beim anlegen der Betriebsspannung an den Controller
Viel Spaß damit und see you here again in six years ! :-)
... so, hier nun meine "finale" Version des TBasic für den STM8. Ich
denke nicht, dass ich den noch einmal wirklich anfassen werde, da der
Speicherbedarf jetzt bei 7730 Bytes liegt.
Ich habe die .zip entpackt, dann per "make -j 8" in basict kompiliert. Auf einem Debian GNU/Linux, mit aktuellem sdcc aus svn trunk (entspricht etwa SDCC 4.4.0 RC2):
1
------ Programm build sucessfull -----
2
3
Device : stm8s103f3 / Flashsize: 8192 bytes
4
Program : at address 0x8000 7236 Bytes (88.3% full)
Wenn ich in makefile.mk noch ein "--max-allocs-per-node 100000" einfüge, um stärker zu optimieren, erhalte ich (bei deutlich längerer Kompilierzeit):
1
------ Programm build sucessfull -----
2
3
Device : stm8s103f3 / Flashsize: 8192 bytes
4
Program : at address 0x8000 7100 Bytes (86.7% full)
Device : stm8s103f3 / Flashsize: 8192 bytes
Program : at address 0x8000 7236 Bytes (88.3% full)
1
Wenn ich in makefile.mk noch ein "--max-allocs-per-node 100000" einfüge,
2
um stärker zu optimieren, erhalte ich (bei deutlich längerer
3
Kompilierzeit):
------ Programm build sucessfull -----
Device : stm8s103f3 / Flashsize: 8192 bytes
Program : at address 0x8000 7100 Bytes (86.7% full)
:-) und führe mich nicht in Versuchung, denn dein ist der Code und die Codegröße und das Programm... und gib mir mehr Speicher so auch ich dir dann mehr Programm gebe!
Oder so ähnlich. Der Speicherplatzgewinn ist dann doch signifikant, so dass dann evtl. eben doch noch einige Funktionen implementiert werden könnten.
Hallo Ralph, vielen Dank für die großartige Arbeit, die Sie an diesem Dolmetscher geleistet haben, ein wahrer Profi! Ich bin Hobbybastler, mein Beruf ist Elektriker und es wäre wirklich schwierig für mich gewesen, einen solchen Job gut zu machen!
1999 hatte ich einen Interpreter für PIC16c54 namens LASI54 entwickelt, der einen seriellen Speicher verwendet, um den Interpretercode mit 10 Anweisungen und 8 Operanden zu speichern, ein schönes Projekt, das ich in meinen Schalttafeln angewendet habe, ich möchte es für Sie zur Analyse veröffentlichen , es ist ganz einfach von einem Elektriker gemacht! :) :)
Danke bis bald!
tbasic_aufbau.jpg
(190 KB)
tbasic_console.png
(56 KB)
stm8s103.jpg
(51 KB)
stlinkv2.jpg
(54 KB)
