Ich habe in den letzten Wochen die Arduino-Umgebung für den STM8S
portiert. Das System baut auf dem SDCC (small devices c compiler) auf,
deshalb habe ich es Sduino genannt - "small devices -uino" oder
"small-duino": https://github.com/tenbaht/sduino/
Neben den zentralen Funktionen rund um pinMode(), analogRead/Write,
digitalRead/Write, delay() und millis() sind auch einige Libraries mit
dabei:
Standard-Libraries: HardwareSerial, I2C, SPI
Motor-Libraries: Stepper und Servo
Display-Libraries: LiquidCrystal für die klassischen Text-LCDs,
Mini_SSD1306 für graphische OLEDs per I2C und und PCD8544 für die
graphischen Nokia-5110 Displays per SPI.
Das klassische blink.c wird euch sehr bekannt vorkommen und sieht dann
für eins dieser 70-cent STM8S103-breakout-board so aus:
1
#include<Arduino.h>
2
3
// Pin 3 for the STM8S103 break out board
4
intled=3;
5
6
voidsetup(){
7
// initialize the digital pin as an output.
8
pinMode(led,OUTPUT);
9
}
10
11
voidloop(){
12
digitalWrite(led,HIGH);// turn the LED on (HIGH is the voltage level)
13
delay(1000);// wait for a second
14
digitalWrite(led,LOW);// turn the LED off by making the voltage LOW
15
delay(1000);// wait for a second
16
}
Das Ganze hat bei meinem letzten Kundenprojekt gewissermaßen als
Nebenprodukt angefangen. Ich habe es in den letzten paar Wochen dann als
Feierabendprojekt vervollständigt und begonnen es zu dokumentieren.
Die verwendeten Tools SDCC, stm8flash und make sind alle für Linux,
MacOS und Windows frei verfügbar.
SDCC kann leider nur C, kein C++. Deshalb ist es logischerweise keine
1:1 Umsetzung des Arduino-Systems, aber dank einiger
Präprozessor-Tricksereien sehr, sehr dicht dran.
Statt wie in C++ im "echten" Arduino-System:
1
#include<LiquidCrystal.h>
2
LiquidCrystallcd(0,1,2,11,12,13);
3
4
voidsetup(){
5
lcd.begin(16,2);
6
lcd.print("hello, world!");
7
}
8
9
10
voidloop(){
11
lcd.setCursor(0,1);
12
lcd.print(millis()/1000);
13
}
Sieht es in meiner C-Version dann so aus:
1
#include<LiquidCrystal.h>
2
LiquidCrystal(lcd,0,1,2,11,12,13);
3
4
voidsetup(){
5
lcd_begin(16,2);
6
lcd_print_s("hello, world!");
7
}
8
9
10
voidloop(){
11
lcd_setCursor(0,1);
12
lcd_print_u(millis()/1000);
13
}
So nah dran wie es der C-Präprozessor möglich macht, der Umbauaufwand
hält sich sehr in Grenzen. In vielen Fällen ist es nur eine verschobene
Klammer bei der Instantierung und danach Unterstriche statt Punkte bei
den Methodenaufrufen.
Die normale ST-Library SPL bleibt verfügbar und kann beliebig mit
Arduino-Zugriffen kombiniert werden.
Vielleicht ist das für den einen oder anderen hier auch interessant.
In der Projekt-Doku erkläre ich die Installation genauer.
https://github.com/tenbaht/sduino/blob/master/docs/index.md
Ich würde mich über Rückmeldungen, ob es jemand anhand der Erklärung
nachvollziehen konnte, freuen.
Michael
>Ich habe in den letzten Wochen die Arduino-Umgebung für den STM8S>portiert.
Sehr gut. Ich finde es immer toll, wenn jemand die Arduino-API auf einen
neuen Prozessor portiert. Oft wird hier ja die Meinung vertreten, dass
die Arduino API zu einfach und für professionelle Anwendungen nicht
geeignet ist. Aber für die schnelle Inbetriebnahme einer neuen MCU ist
es auf jeden Fall sehr gut.
Das Problem mit nur 'c' anstatt 'c++" hatte ich auch schon und habe es
ähnlich wie Du mit '_' simuliert. Leider geht die Polymorphie mit C
nicht.
Was auf jeden Fall immer sehr wichtig ist: Die serielen Funktionen wie
Serial_println ..
Also Repekt vor der Leistung und so.
Aber sind die STM8S mit ihrer Akkumulator-Architektur nicht eher Relikte
aus einer längst vergessen geglaubten Zeit?
Kann sein, dass ich mit meiner Meinung da recht einsam bin, aber ich
würde die Dinger nicht mal geschenkt nehmen.
ChrisMicro schrieb:> Oft wird hier ja die Meinung vertreten, dass> die Arduino API zu einfach und für professionelle Anwendungen nicht> geeignet ist. Aber für die schnelle Inbetriebnahme einer neuen MCU ist> es auf jeden Fall sehr gut.
Ja. Stimmt, sie ist zu einfach für "ernsthafte" Anwendungen.
Aber die gesamte Inbetriebnahme geht unglaublich schnell. Und die Menge
an Libraries für fast alles ist unglaublich hilfreich. 90% der
Funktionen der meisten Anwendungen lassen sich so rasend fix hinzaubern.
Und dann gibt es die restlichen 10%. Der Teil, der dann richtig Spaß
macht, der speziellen C- oder sogar Assemblercode erfordert. Wo richtig
debuggt werden muss. Und für den so mehr Zeit zur Verfügung steht, wenn
die Routineaufgaben vorher fix aus dem Weg geräumt wurden.
Das tolle am Arduino-System ist, dass es bei diesen restlichen 10% nicht
im Weg steht. Der Weg direkt auf die Hardware steht trotzdem komplett
offen. Das ist nicht bei jedem Librarykonzept so. Deshalb fange ich doch
immer wieder mit Arduino-Kram an, obwohl dieser Rahmen jedes Mal wieder
früher oder später zu eng wird. Aber dann kann ich das und habe nichts
verloren.
> Das Problem mit nur 'c' anstatt 'c++" hatte ich auch schon und habe es> ähnlich wie Du mit '_' simuliert. Leider geht die Polymorphie mit C> nicht.
Ja, den Teil vermisse ich ständig. Workaround ist name mangling von
Hand:
Serial.print(unsigned) -> Serial_print_u()
Serial.print(int) -> Serial_print_i()
Serial.print(char) -> Serial_print_c()
Serial.print(float) -> Serial_print_f()
usw. Da konnte ich leider keinen automatismus finden.
> Was auf jeden Fall immer sehr wichtig ist: Die serielen Funktionen wie>> Serial_println ..
Sind natürlich drin. Die Vererbung von Print nach Serial oder in die
diversen Display-Libraries mit dem Präprozessor hinzubekommen hat ein
paar Verrenkungen erfordert, klappt aber.
Vererbung wird als Funktionsaufruf mit einem Funktionspointer als erstem
Argument übersetzt. C++ macht es intern sehr ähnlich, da ist aber noch
ein zusätzlicher Level an dereferenzierung nötig.
lcd_print_i(val); --> Print_print_i(LiquidCrystal_write, val);
Serial_print_i(val); --> Print_print_i(HardwareSerial_write, val);
Rudolph R. schrieb:> Aber sind die STM8S mit ihrer Akkumulator-Architektur nicht eher Relikte> aus einer längst vergessen geglaubten Zeit?
Damit kommt man ja erst auf Assembler-Ebene in Kontakt. In C merkt das
keiner. Und erstaunlicher Weise unterscheiden sich die erzeugten
Codegrößen nicht allzu arg zwischen avr-gcc und sdcc für STM8. Obwohl es
mich regelmäßig schüttelt, wenn ich in die Assemblerlistings schaue und
ich mich ständig zwingen muss, es gut sein zu lassen und nicht alles in
Assembler neu zu schreiben. Ich könnte das sooo viel besser als der
Compiler... Würde aber nie fertig.
Manches ist wirklich auf dem Atmel viel, viel besser, anderes kommt am
Ende auf dem STM8 kompakter raus. In einer realen Anwendung mittelt sich
das fast aus.
> Kann sein, dass ich mit meiner Meinung da recht einsam bin, aber ich> würde die Dinger nicht mal geschenkt nehmen.
Dazu schreibe ich in der Projektdoku auch ein wenig:
https://github.com/tenbaht/sduino/blob/master/docs/index.md#why-use-a-stm8-instead-of-an-atmega
Zuhause geht es eher um Wissbegier. Atmel ist meist sinnvoller um ein
Problem zu lösen. Für kommerzielle Produkte haben die STM8 aber echte
Vorteile.
Und die Dinger machen Spaß. Die machen zum Teil Sachen in Hardware, die
ich beim Atmel erst von Hand in Software programmieren müsste. Es gibt
zum Beispiel einen Quadratur-Endcoder-Modus für den Timer: Drehgeber
anschließen, Timer programmieren und schon findet sich die aktuelle
Motorposition immer ganz frisch im Timer-Register. Ohne jeden Interrupt.
Auf Wunsch mit automatischer Endabschaltung bei Ereichen einer
bestimmten Position.
Überhaupt: Die Teile sind ganz speziell auf Motorsteuerungen und
mehrphasige rückgekoppelte PWM-Systeme ausgelegt. Mit
Highside/Lowside-Totzeiten, Phasen-Totzeiten, Positonstracking und
Notabschaltung unabhänig von der CPU.
Die Dinger haben extrem gute Stromsparmodi. Auf dem Datenblatt sieht
Atmel fast genauso aus. In der Realität komme ich mit dem STM8 fast
dreimal so lange mit einer Batterie hin.
Die Peripherie ist weitgehend identisch mit der STM32-Reihe. Wer die SPL
(oder Arduino!) verwendet, kann seine Software bei Bedarf sehr leicht
von 8 auf 32 Bit portieren.
Und nicht zuletzt sind sie unschlagbar günstig. 40 cent statt 1,60€ bis
2€ bei ähnlicher Leistung. Zuhause egal, bei Stückzahlen wichtig.
Michael
Tim . schrieb:> Eine Möglichkeit, C++ für STM8 zu compilieren wäre evtl. der Umweg über> LLVM:>> http://www.colecovision.eu/llvm+sdcc/>> Leider etwas umständlich...
Ja, hab' ich drüber nachgedacht. Ich bin auch immer noch versucht, es
einfach mal durchzuziehen und das Resultat zu vergleichen.
Hauptfrage ist, wie ich die CPU-spezifischen Sonderkommandos wie
__interrupt oder die Zeropage-Adressierung durchbekomme.
Die STM8 sind doch eigentlich relativ neu, oder? Ich war über die
Akku-basierte ISA auch etwas erstaunt. Die Implementierung ist
allerdings eher modern - single clock und tiefes Pipelining. Nicht so
ein 70er Jahre Gefrickel wie beim PIC. Dazu scheint man bei allen
Designs gleich auf 130nm gesetzt zu haben, wodurch vergleichsweise viel
SRAM und Flash möglich sind.
Das Ergebnis spricht für sich: Exzellente Codedichte und das beste
Preis/Leistungsverhältnis am Markt.
Michael M. schrieb:> Hauptfrage ist, wie ich die CPU-spezifischen Sonderkommandos wie> __interrupt oder die Zeropage-Adressierung durchbekomme.
Tja - gute Frage. Allerdings muss es dazu auch für andere MCUs Lösungen
geben? z.B. LLVM-AVR oder AVR-Rust
> Die STM8 sind doch eigentlich relativ neu, oder?
Die STM8 sind aufgebohrte ST7. Und die sind genauso alt wie Braunkohle.
Drangepappt hat Mann Teile der Peripherie des STM32.
Oder umgekehrt.
Wer mit dem 6502 des C64 klargekommen ist, wird mit dem
STM8 in Assembler seine Freude haben.
Und, selbst die kleinsten die Mann kaufen kann (nicht die
kleinsten im Datenbuch) haben schon 2 kByte RAM.
Nach oben sieht es aber mager aus. Der Klassengroesste
STM8S208 hat "nur" 6 kByte RAM und 128 kByte Flash.
Da will Mann vielleicht dann doch was anderes nehmen.
(º°)·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.· schrieb im Beitrag
#4903607:
>> Die STM8 sind doch eigentlich relativ neu, oder?>> Die STM8 sind aufgebohrte ST7. Und die sind genauso alt wie Braunkohle.
Wenn das ein Argument wäre ... alle aktuellen Architekturen sind doch
irgendwie nur aufgebohrte Varianten ihrer Vorgänger oder Vorbilder.
> Wer mit dem 6502 des C64 klargekommen ist, wird mit dem> STM8 in Assembler seine Freude haben.
Der STM8 ist bei weitem fortschrittlicher als der 6502. Der steckt sogar
den Z80 in die Tasche (und ich war damals ein großer Fan des Z80). Und
wie Vorposter bemerkten: die Codedichte ist gut vergleichbar mit den
AVR. Und das obwohl der SDCC bei weitem weniger Mannjahre im
Codegenerator + Optimizer hat als der avr-gcc.
> Nach oben sieht es aber mager aus. Der Klassengroesste> STM8S208 hat "nur" 6 kByte RAM und 128 kByte Flash.> Da will Mann vielleicht dann doch was anderes nehmen.
Wenn 128K Flash nicht reichen, dann ist ein 8-Bitter wohl von vorn
herein die falsche Wahl gewesen. Aber auch das wurde ja schon gesagt:
die Peripherie ist bei STM8 und STM32 sehr ähnlich. Ein Umstieg ist also
sehr einfach. Alle anderen architektonischen Unterschiede verdeckt der
Compiler ohnehin.
Philipp Klaus K. schrieb:>> Serial.print(unsigned) -> Serial_print_u()>> Serial.print(int) -> Serial_print_i()>> Serial.print(char) -> Serial_print_c()>> Serial.print(float) -> Serial_print_f()>> #define Serial_print(X) _Generic((X), int: Serial_print_i, char:> Serial_print_c, float: Serial_print_f)(X)
Der Tip ist genial, danke! Diese Funktion kannte ich noch gar nicht und
sdcc unterstützt es sogar in den neueren builds. Für Situationen mit
festen Instanz-Namen wie Serial würde das klappen.
Jetzt bräuchte ich noch einen Trick, wie ich das auch wieder für
flexible Instanz-Namen anpasse. Ganz wichtig würde das z.B. bei
SoftwareSerial. Oder Beispiel PCD8544-Library: Meistens wird man die
Instanz lcd nennen, das ist aber nicht in Stein gemeisselt. Im Moment
geht so etwas mit frei wählbarem Namen:
1
// PCD8544 lcd(1,2,3,4,5); // so wäre es in C++
2
PCD8544(lcd,1,2,3,4,5);// so ist es in C jetzt
3
4
setup(){
5
lcd_begin();
6
lcd_print_s("Hello World!");
7
}
Weil der Präprozessor nur einen Durchlauf macht, sind #defines mit
parametrierbaren Namen leider nicht drin und ich habe mich mit
inline-Funktionen beholfen. Es wird erzeugt:
1
inlinevoidlcd_inst(void){
2
LCD8544_connection(1,2,3,4,5);
3
}
4
inlinevoidlcd_begin(void){
5
lcd_inst();
6
PCD8544_begin_full(84,48,CHIP_PCD8544);
7
}
8
inlinesize_tlcd_print_s(constchar*arg1){
9
returnPrint_print_s(PCD8544_write,arg1);
10
}
11
setup(){
12
lcd_begin();
13
lcd_print_s("Hello World!");
14
}
Was der Compiler dann blitzsauber ohne jeden Overhead genau so
übersetzt, als ob man die echten Funktionsaufrufe selbst innerhalb von
setup() geschrieben hätte und dabei die Pinzuordung verwendet, die viel
weiter oben im Deklarationsteil angegeben wurde.
Wenn ich das jetzt noch mit dem _Generic kombinieren könnte...
Ansonsten müsste ich mich entscheiden ob ich den flexiblen Instanznamen
haben will oder lieber die polymorphen Print-Methoden. Bei den
Display-Libraries wäre ein fixer Name ja noch halbwegs ok, aber bei
SoftwareSerial nimmt es viel vom Nutzwert.
Hast Du da vielleicht noch eine Idee?
Michael
Hallo Michael,
ich versuche gerade, die Windows-Version von Sduino zum laufen zu
bringen.
Im Moment steigt das Makefile (Arduino.mk) an folgender Stelle aus:
1
# moved from above so we can find version-dependant ar
2
ifndef AR_NAME
3
ifeq ($(shell expr $(CC_VERNUM) '>' 490), 1)
4
AR_NAME = avr-gcc-ar
5
else
6
AR_NAME = avr-ar
7
endif
8
endif
Wenn ich sdcc -v aufrufe, dann bekomme ich als Ausgabe
Das heißt, es kommt keine reine Zahl raus. Daher gibt's dann in der expr
einen Syntax Error.
Wenn ich dann im Makefile die Versionsnummer hart setze mit
1
CC_VERNUM = 365
dann läuft das Makefile deutlich weiter. Allerdings endet es wieder mit
einer Fehlermeldung:
Ich hatte die Frage vor ein paar Monaten hier gar nicht mitbekommen...
Auf jeden Fall noch Danke für die Fehlermeldung, Problem ist jetzt
behoben.
In der Zwischenzeit habe ich es auch hinbekommen, dass es sogar in der
IDE läuft und ganz einfach mit dem Boardmanager installiert werden kann.
Das erspart unter Windows diese ganze Pfad-Fummelei.
Einfach in den Einstellungen
https://github.com/tenbaht/sduino/raw/master/package_sduino_stm8_index.json
als neue "Board Package URL" eintragen und im Board Manager dann
"Sduino" auswählen.
Falls Du doch lieber auf der Kommandozeile arbeitest:
Die Makefile-Geschichte ist unter Windows generell recht wackelig. Das
Problem mit der Versionsabfrage ist (durch weglassen) mittlerweile
gelöst.
Das Compiler-Problem entsteht, weil Du den SDCC offenbar nicht im
passenden Verzeichnis hast: Er sollte als
hardware/sduino/tools/sdcc/bin/sdcc.exe aufrufbar sein.
Ich habe mittlerweile auch die Anleitung für die Installation im
Handbetrieb noch einmal neu geschrieben:
https://tenbaht.github.io/sduino/usage/manual-install/
Michael M. schrieb:> In der Zwischenzeit habe ich es auch hinbekommen, dass es sogar in der> IDE läuft und ganz einfach mit dem Boardmanager installiert werden kann.> Das erspart unter Windows diese ganze Pfad-Fummelei.
sieht interessant aus; Installation unter win10/IDE1.8.4 klappt,
compilieren irgendwie nicht, hier der erste Versuch mit blink:
Jan L. schrieb:> sieht interessant aus; Installation unter win10/IDE1.8.4 klappt,> compilieren irgendwie nicht, hier der erste Versuch mit blink:
Dieser Fehler sollte seit Version 0.3.1 behoben sein. Könntest Du bitte
im Boardmanager nachsehen, ab Du wirklich die aktuelle Version
installiert hast? Und noch einmal mit der aktuellen Version 0.3.2
testen?
Michael
Michael M. schrieb:> Jan L. schrieb:>>> sieht interessant aus; Installation unter win10/IDE1.8.4 klappt,>> compilieren irgendwie nicht, hier der erste Versuch mit blink:>> Dieser Fehler sollte seit Version 0.3.1 behoben sein. Könntest Du bitte> im Boardmanager nachsehen, ab Du wirklich die aktuelle Version
in den Boardmanager hatte ich per Cut&Paste obige URL eingetragen; hier
gerne nochmal zurück-gepastet:
https://github.com/tenbaht/sduino/raw/master/package_sduino_stm8_index.json> installiert hast? Und noch einmal mit der aktuellen Version 0.3.2
offenbar nicht, denn die Ausgabe liefert auch sowas:
Using core 'sduino' from platform in folder:
...\Arduino15\packages\sduino\hardware\stm8\0.3.1
Hat sich die Version evtl. erst nach dem Post der URL hier verändert?
Ich glaube nicht, dass ich vorher bereits 0.3.1 drauf hatte...(die würde
dann ja auch "im anderen" Arduino-Folder liegen)
[Update] - nachdem ein wget auf die Boardmamanger-URL einen
Zertifikatsfehler meldet, habe ich die URL mal auf "http://"; geändert -
und siehe da, plötzlich wird mir ein Update auf 0.3.2 angeboten.
Selbiges scheitert allerdings, da bereits "im Fensterrahmen" des
Boardmanagers die Fehlermeldung erscheint:
Ja, es ist doch wieder ein Link reingerutscht. Er ist aber überflüssig
und die Installation hat trotzdem funktioniert (auch wenn es nicht so
aussieht).
Der Zertifikatsfehler ist seltsam, den habe ich noch nie gesehen. Es ist
eine ganz normale Datei auf github, das sollte eigentlich keine Probleme
geben, sonst würde ja die ganze Webseite nicht funktionieren.
Bei mir sieht das so aus:
Mich wundert auch sehr, dass Du bei 0.3.1 das Problem mit cp und rm
gesehen hast. Da ist eigentlich schon eine Korrektur drin die auch sonst
bei anderen Leuten funktioniert hat. Es würde mich sehr interessieren,
was da genau passiert.
Wenn es noch immer klemmt probier doch vielleicht erst einmal ein packet
remove, bevor Du dann ganz frisch die 0.3.2 installierst (und die
ln-Meldung ignorierst).
Die 0.x.x-Versionsnummer hat ihren Grund... Da ist nicht alles so stabil
wie ich es gerne hätte und ich freue mich über nützliche Rückmeldung.
Leider lassen sich diese Board-Manager Sachen immer nur per Release
testen, nicht per git clone.
Michael M. schrieb:> Ja, es ist doch wieder ein Link reingerutscht. Er ist aber überflüssig> und die Installation hat trotzdem funktioniert (auch wenn es nicht so> aussieht).
Ok, werde ich ausprobieren.
>> Der Zertifikatsfehler ist seltsam, den habe ich noch nie gesehen. Es ist
...kenne ich bei solchen Downloadlinks durchaus - das Cert gilt bloss
für "[www.]github.com", es erfolgt aber ein Redirect auf
"https://raw.githubusercontent.com";...
aber wie gesagt, ob das hier überhaupt eine Rolle gespielt hat - k.A.
> eine ganz normale Datei auf github, das sollte eigentlich keine Probleme> geben, sonst würde ja die ganze Webseite nicht funktionieren.
s.o.
>> Bei mir sieht das so aus:
ich muss dafür "--no-check-certificate" hinzufügen :) - ist bei dir
vielleicht Default? [.wgetrc]
>> Mich wundert auch sehr, dass Du bei 0.3.1 das Problem mit cp und rm> gesehen hast. Da ist eigentlich schon eine Korrektur drin die auch sonst> bei anderen Leuten funktioniert hat. Es würde mich sehr interessieren,> was da genau passiert.>> Wenn es noch immer klemmt probier doch vielleicht erst einmal ein packet> remove, bevor Du dann ganz frisch die 0.3.2 installierst (und die> ln-Meldung ignorierst).
Habe "sduino" entfernt, per Boardmanager 0.3.2 neu installiert,
ln-Fehler ignoriert, Boards sind da.
Kompilieren von "Blink" bricht allerdings wieder ab mit "cp" und "rm not
found"...
>> Die 0.x.x-Versionsnummer hat ihren Grund... Da ist nicht alles so stabil> wie ich es gerne hätte und ich freue mich über nützliche Rückmeldung.> Leider lassen sich diese Board-Manager Sachen immer nur per Release> testen, nicht per git clone.
Jan L. schrieb:> Habe "sduino" entfernt, per Boardmanager 0.3.2 neu installiert,> ln-Fehler ignoriert, Boards sind da.> Kompilieren von "Blink" bricht allerdings wieder ab mit "cp" und "rm not> found"...
Erstaunlich. Das ist mit Sicherheit wieder so eine Backslash-Geschichte.
Ich habe noch nie verstanden, was die geritten hat, ausgerechnet das
speziellste aller Sonderzeichen zum Pfadbestandteil zu machen... Bevor
ich nur zum Testen ein release baue könntest Du vielleicht in
...\AppData\Local\Arduino15\packages\sduino\tools\STM8Tools\2017.11.06/w
rapper/sdcc.sh
bei der PATH-Anpassung in Zeile 49 noch zwei Gänsefüßchen so anbringen:
1
# check if cp is in the path, add our binaries to the PATH if needed
Entsprechend auch in sdar.sh Zeile 38 und sdcc-link.sh Zeile 40. Das
sollte dann aber wirklich helfen. Hier habe ich es mit ein paar "echo
$PATH" Befehlen auf einem System ohne cygwin o.ä. getestet und es sieht
sehr gut aus.
Michael M. schrieb:> Jan L. schrieb:>> Habe "sduino" entfernt, per Boardmanager 0.3.2 neu installiert,>> ln-Fehler ignoriert, Boards sind da.>> Kompilieren von "Blink" bricht allerdings wieder ab mit "cp" und "rm not>> found"...>> Erstaunlich. Das ist mit Sicherheit wieder so eine Backslash-Geschichte.> Ich habe noch nie verstanden, was die geritten hat, ausgerechnet das> speziellste aller Sonderzeichen zum Pfadbestandteil zu machen... Bevor> ich nur zum Testen ein release baue könntest Du vielleicht in> ...\AppData\Local\Arduino15\packages\sduino\tools\STM8Tools\2017.11.06/w
rapper/sdcc.sh
> bei der PATH-Anpassung in Zeile 49 noch zwei Gänsefüßchen so anbringen:>>
1
> # check if cp is in the path, add our binaries to the PATH if needed
sorry, aber das macht keinen Unterschied.
Ich hatte - da $PATH sowohl "\" als auch "/" enthielt - einfach auch
jeweils mal ein
PATH="${PATH//\//\\}" oder
PATH="${PATH//\\/\/}"
drangehängt - macht auch keinen Unterschied (ausser dass der Pfad dann
einheitliche Trenner enthält)...
Aussehen tut $PATH zwar gut (= existiert), "cp" wird aber trotzdem
nicht gefunden. Leider sind meine "bash-unter-DOS"-Kenntnisse recht
überschaubar...
Dirty Harry kommt allerdings einen Schritt weiter, wenn "cp" ersetzt
wird durch
$0/../../win/cp
(ausserdem muss "rm" "ausser Betrieb" bleiben, andernfalls wird der
Source nicht gefunden (sinngemäss))
Das liefert dann allerdings
>> Entsprechend auch in sdar.sh Zeile 38 und sdcc-link.sh Zeile 40. Das> sollte dann aber wirklich helfen. Hier habe ich es mit ein paar "echo> $PATH" Befehlen auf einem System ohne cygwin o.ä. getestet und es sieht> sehr gut aus.
Jan L. schrieb:>> Erstaunlich. Das ist mit Sicherheit wieder so eine Backslash-Geschichte.
ich glaube eher nicht - es ist imo eher eine
"bash-unter-DOS"-Geschichte.
Nebenbei wollte ich kurz die Meckerei über ein fehlendes /tmp abstellen
- was nicht per c:\tmp funktionierte.
Ein "mkdir /tmp" in einem der Wrapper-Scripte lieferte die Erkenntnis,
dass für diese bash hier "root" unter ...../SDM8Tools liegt.
Folgerichtig funktioniert nun auch ein
cp --version >/dev/null 2>&1 || PATH="/2017.11.06/win":$PATH
wobei ich das Rausfummeln des Datums aus $0 lieber den Profis
überlasse... ;-)
Die Linkerfehler bleiben natürlich leider...
Jan L. schrieb:> sorry, aber das macht keinen Unterschied.
Ich habe hier zum Testen eine virtuelle Maschine mit Windows 7 Home,
Arduino 1.8.5 und ohne cygwin oder mingw PATH-Definitionen. Da klappt es
so prima:
1
# not need, but gives us lots of debug information
2
set -x
3
# check if cp is in the path, add our binaries to the PATH if needed
> Ich hatte - da $PATH sowohl "\" als auch "/" enthielt - einfach auch> jeweils mal ein> PATH="${PATH//\//\\}" oder> PATH="${PATH//\\/\/}">> drangehängt - macht auch keinen Unterschied (ausser dass der Pfad dann> einheitliche Trenner enthält)...
Da ist ein Strich zu viel am Anfang. Du meintest sicher
PATH="${PATH/\\//}" oder PATH="${PATH/\\/\/}" ? Es müsste aber auch mit
dem gemischten Pfad prima klappen.
> Aussehen tut $PATH zwar gut (= existiert), "cp" wird aber trotzdem> nicht gefunden. Leider sind meine "bash-unter-DOS"-Kenntnisse recht> überschaubar...> Dirty Harry kommt allerdings einen Schritt weiter, wenn "cp" ersetzt> wird durch>> $0/../../win/cp
Das ist wirklich dreckig. Sollte für rm dann aber genauso klappen. So
etwas ähnliches wäre dann mein Plan B, falls der PATH wirklich nicht
will. Aber vorher wüsste ich gerne, was genau bei Dir schief läuft
obwohl es hier klappt, damit ich das demnächst gleich mit testen kann.
> (ausserdem muss "rm" "ausser Betrieb" bleiben, andernfalls wird der> Source nicht gefunden (sinngemäss))
??? Wieso sollte ein rm nach dem compilieren ein Problem beim
compilieren machen? Da wird doch irgendwas wohin kopiert, wo es gar
nicht hingehört? Könntest Du mir da vielleicht mal das komplette log
schicken? Vielleicht setzten wir diese Diskussion auch besser per email
(an michael-mayer@gmx.de) oder auf der Sduino-Seite im Issue-Tracker
fort. Dieses Thema wird hier vielleicht etwas zu speziell für ein
Elektronik-Forum.
> Das liefert dann allerdings> Multiple definition of _setup>> Multiple definition of _loop
Klar, wenn die Kopie der ursprünglichen cpp-Datei nicht gelöscht wird,
wird sie eben zweimal compiliert. Deshalb ja das rm.
Jan L. schrieb:> Ein "mkdir /tmp" in einem der Wrapper-Scripte lieferte die Erkenntnis,> dass für diese bash hier "root" unter ...../SDM8Tools liegt.> Folgerichtig funktioniert nun auch ein>> cp --version >/dev/null 2>&1 || PATH="/2017.11.06/win":$PATH
Danke für diesen Tip! Ich habe Deinen Parallel-Post erst nach dem
Abschicken eben gelesen. Diese Info hilft sehr, da kann ich mir etwas
einfallen lassen!
Michael M. schrieb:>> Multiple definition of _loop>> Klar, wenn die Kopie der ursprünglichen cpp-Datei nicht gelöscht wird,> wird sie eben zweimal compiliert. Deshalb ja das rm.
stimmt, muss wohl irgendein "Zwischenproblem" mit halb-gefixten Pfaden
gewesen sein; nach dem Ändern s.o. von $PATH in allen 3 Wrappern tut's
nun! :-)
Jan L. schrieb:> stimmt, muss wohl irgendein "Zwischenproblem" mit halb-gefixten Pfaden> gewesen sein; nach dem Ändern s.o. von $PATH in allen 3 Wrappern tut's> nun! :-)
Gut. Ich bin jetzt an der Sache mit dem root-Directory dran. Irgendwie
erinnern sich alle Tools in win/ daran, dass sie aus einem Archiv
stammen, dass ursprünglich in STM8Tools entpackt wurde. Mir ist aber
nicht klar, wie die Information aufbewahrt wird und wie sie dort
hinkommt. Environment-Variablen und Windows Registry habe ich mir
angesehen, da ist kein Hinweis auf dieses Verzeichnis. Aber selbst wenn
ich die bash per Hand aus cmd.exe heraus starte, erinnert sie sich an
dieses Verzeichnis. Woher weiss die das?
Könntest Du in sdcc.sh vor dem PATH setzen noch diese Zeile einbauen und
mir die Ausgabe schicken?
> echo "pwd: " $(pwd)
Bei mir kommt da
> pwd: /cygdrive/c/Program Files/Arduino
Wie hast Du Arduino auf Deinem Rechner installiert? Systemweit oder nur
für einen User? Ist es also in Deinem Userverzeichnis oder unter
c:\Programme\Arduino ?
Könntest Du das vielleicht kurz ausprobieren? Bei mir kommt er ohne
Gänsefüßchen aus. Klappt das bei Dir auch?
Es bleibt aber die Grundfrage, wie der überhaupt auf die Idee kommt,
ausgerechnet STM8Tools als root zu verwenden.
>> Könntest Du in sdcc.sh vor dem PATH setzen noch diese Zeile einbauen und> mir die Ausgabe schicken?>> echo "pwd: " $(pwd)>> Bei mir kommt da>> pwd: /cygdrive/c/Program Files/Arduino
...da das Zeug bei mir auf D: liegt:
pwd: /cygdrive/d/Programme/Arduino
>> Wie hast Du Arduino auf Deinem Rechner installiert? Systemweit oder nur> für einen User? Ist es also in Deinem Userverzeichnis oder unter> c:\Programme\Arduino ?
Systemweit, aber eben auf D:...
Michael M. schrieb:> # dirty, but it works:> cd $0/../..> cp --version >/dev/null 2>&1 || PATH=$(pwd)/win:$PATH>> Könntest Du das vielleicht kurz ausprobieren? Bei mir kommt er ohne> Gänsefüßchen aus. Klappt das bei Dir auch?
Ja; sehe jetzt allerdings keinen "qualitativen" Unterschied zur Version
von Dirty Harry... ;-)
Michael M. schrieb:> Es bleibt aber die Grundfrage, wie der überhaupt auf die Idee kommt,> ausgerechnet STM8Tools als root zu verwenden.
...ist das root-Verz. bei Cygwin nicht sowieso ein "Parameter" der
Installation? Kann mich dunkel erinnern, dass bei mir damals "root" in
"C:\cygwin" lag - was aber afair beim Install änderbar war.
K.A. wie jetzt deine Binaries entstanden sind, aber so weit hergeholt
fände ich das jetzt nicht, dass ein "build script", "make" o.ä. das
aktuelle Verz. zum "root" macht, z.B. falls nicht anders angegeben...
Michael M. schrieb:> Da ist ein Strich zu viel am Anfang. Du meintest sicher> PATH="${PATH/\\//}" oder PATH="${PATH/\\/\/}" ?
nope; "To replace all matches of $pattern with $replacement, double the
first slash:"...
(Ergebnis entsprach ja auch dem Erwarteten)
nur der Vollständigkeit halber... :)
Jan L. schrieb:> Ja; sehe jetzt allerdings keinen "qualitativen" Unterschied zur Version> von Dirty Harry... ;-)
Leider wahr. Ich habe noch etwas aufgeräumt, jetzt sieht es sauber aus
und sollte überall laufen. Könntest Du das hier bitte mal ausprobieren:
1
# check if cp is in the path
2
if ! command -v cp > /dev/null; then
3
# Alternative 3: Geht zumindest bei mir.
4
cd "${0%/wrapper/*}"
5
PATH=$(pwd)/win:$PATH
6
fi
Und um sicher zu sein, dass wir nicht aneinander vorbeigeredet haben:
Könntest Du bitte noch diese zwei Alternativen anstelle von Alternative
3 einsetzten und testen ob es geht oder nicht?
1
# Alternative 1: geht bei mir, bei Dir aber nicht (Warum?):
2
PATH="${0%/wrapper/*}"/win:$PATH
3
4
# Alternative 2: Eigentlich falsch, klappt unter Windows aber trotzdem:
5
cd $0/../..
6
PATH=$(pwd)/win:$PATH
Wenn das so klappt, kann ich morgen ein update fertig machen.
Michael M. schrieb:> Jan L. schrieb:>> Ja; sehe jetzt allerdings keinen "qualitativen" Unterschied zur Version>> von Dirty Harry... ;-)>> Leider wahr. Ich habe noch etwas aufgeräumt, jetzt sieht es sauber aus> und sollte überall laufen. Könntest Du das hier bitte mal ausprobieren:>>
1
> # check if cp is in the path
2
> if ! command -v cp > /dev/null; then
3
> # Alternative 3: Geht zumindest bei mir.
4
> cd "${0%/wrapper/*}"
5
> PATH=$(pwd)/win:$PATH
6
> fi
7
>
funktioniert
>> Und um sicher zu sein, dass wir nicht aneinander vorbeigeredet haben:> Könntest Du bitte noch diese zwei Alternativen anstelle von Alternative> 3 einsetzten und testen ob es geht oder nicht?>>
1
> # Alternative 1: geht bei mir, bei Dir aber nicht (Warum?):
2
> PATH="${0%/wrapper/*}"/win:$PATH
3
4
funktioniert nicht
5
(war ja irgendwie system-root != bash-root...)
6
7
>
8
> # Alternative 2: Eigentlich falsch, klappt unter Windows aber
Jan L. schrieb:
Danke für die Tests, dann werde ich das so in 0.3.3 einbauen.
> (edit: Linkparser tut's nicht, ging um: PATH="/2017.11.06/win":$PATH)>> noch am wenigsten "aufträgt", und auch keinerlei zusätzliche externe> Aufrufe benötigt werden.
So wäre es von der Versionsnummer des Release-Packets abhängig.
Ausserdem traue ich dem Braten nicht so ganz, weil mir noch immer nicht
klar ist, wo dieser root-Pfad eigentlich festgelegt wird. Womöglich ist
der auf anderen Rechnern ganz anders. Hier bei mir hat er auch dieses
root, aber ein kompletter, C:\-basierter Pfad (Alternative 1)
funktioniert trotzdem. Bei Dir geht der nicht. Warum auch immer. Es gibt
da noch irgendwelche feinen Unterschiede, von denen ich nichts weiß.
Die neue Lösung trägt übrigens auch nicht auf und hat keine externen
Abhängkeiten, weil nur bash-interne POSIX-Funktionen verwendet werden:
command, pwd, cd und Musterersetzung in Variablen.
Mittlerweile habe ich so viel über DOS-Batchprogrammierung gelesen dass
ich mir sogar den kompletten Verzicht auf diese Zusatztools vorstellen
könnte. Aber das gibt dann wieder viele neue Fehlerquellen...
Auf jeden Fall vielen Dank für die Mithilfe!
Michael M. schrieb:> Mittlerweile habe ich so viel über DOS-Batchprogrammierung gelesen dass> ich mir sogar den kompletten Verzicht auf diese Zusatztools vorstellen> könnte.
...mir kam da auch ein Gedanke an "Powershell", ist ja inzwischen mehr
oder weniger voraussetzbar. Bliebe dann aber immer noch ein
Win-Sonderstrick.
Vielleicht einheitlich auf Python wechseln? :)
Moin. Ist ja nun schon länger ruhiger hier.
Trotzdem eine ganz blöde frage, hier wird ja SDCC genutzt um STM8 zu
programmieren.
Könnte man Sduino umschreiben um SDCC zu nutzen um 8051 zu programmieren
denke da an die CH552 usw. Chips von WCH diese haben einen C8051 kern
und es gibt eine SDCC portierung um diese zu programmieren.
Hier die SDCC portierung: https://github.com/Blinkinlabs/ch554_sdcc
Und hier weitere infos zu den CH55x chips:
https://www.electrodragon.com/w/WCH#MCU_.2B_USB_CH55x_Series
Da das alles Quelloffen ist, kannst du es so weit umschreiben, wie du
möchtest - wenn du dazu qualifiziert bist. Versuche es doch, dann wirst
du ein weiterer Unterstützer des Arduino Projektes.
Ja, kann man machen. Der Hardware-abhängige Teil (I/O-Pins, PWM, Timer
etc.) ist natürlich komplett anders, aber die grundsätzliche Struktur
und die Präprozessor-Klimmzüge sollten 1:1 funktionieren.
Wenn Du Dich mit dem 8051 auskennst, sollte zumindest der Anfang
(digitalWrite, digitalRead, pinMode, millis() und der 1ms-Timer) leicht
sein.
analogRead ist dann auch nicht so schlimm, erst analogWrite wird dann
etwas fummeliger.
Die Serielle ist dann auch wieder leicht. Die ganzen Print-Geschichten
müsstest Du auch 1:1 übernehmen können, alles was es braucht sind ein
paar elementare Funktionen in HardwareSerial: init, read, write. Der
schwierigste Teil wird dabei das Interrupt-Handling für den Empfang und
das Senden sein, aber die Puffer-Logik kannst Du auch schon wieder
übernehmen.
Damit würdest Du dann schon sehr weit kommen und es könnte in ein paar
Tagen zu schaffen sein (wenn Du mit der Hardware und dem Compiler schon
Erfahrungen hast).
Schwieriger wird es dann erst wieder bei der Integration in die
Arduino-IDE. Die platform.txt und die wrapper-Skripte (falls Du Windows
verwendest) könnten Ärger machen. Der Compiler wird bestimmt ein paar
andere Flags brauchen und die Ausgaben haben möglicherweise ein etwas
abweichendes Format, das dann umgebaut werden muss.
Viel Erfolg,
Michael
Thread beobachten
Seitenaufteilung abschalten