mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik SDuino: Beinahe-Arduino für STM8S


Autor: Michael Mayer (tenbaht)
Datum:

Bewertung
13 lesenswert
nicht lesenswert
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:
#include <Arduino.h>

// Pin 3 for the STM8S103 break out board
int led = 3;

void setup() {
  // initialize the digital pin as an output.
  pinMode(led, OUTPUT);
}

void loop() {
  digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);               // wait for a second
  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);               // wait for a second
}

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:
#include <LiquidCrystal.h>
LiquidCrystal lcd(0,1,2,11,12,13);

void setup() {
  lcd.begin(16, 2);
  lcd.print("hello, world!");
}


void loop() {
  lcd.setCursor(0, 1);
  lcd.print(millis() / 1000);
}

Sieht es in meiner C-Version dann so aus:
#include <LiquidCrystal.h>
LiquidCrystal (lcd,0,1,2,11,12,13);

void setup() {
  lcd_begin(16, 2);
  lcd_print_s("hello, world!");
}


void loop() {
  lcd_setCursor(0, 1);
  lcd_print_u(millis() / 1000);
}
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

Autor: ChrisMicro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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 ..

Autor: Rudolph R. (rudolph)
Datum:

Bewertung
-7 lesenswert
nicht lesenswert
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.

Autor: Michael Mayer (tenbaht)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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);

Autor: Tim    (cpldcpu)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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...

Autor: Michael Mayer (tenbaht)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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...

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

Autor: Michael Mayer (tenbaht)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tim    (cpldcpu)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Tim    (cpldcpu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: (º°)·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.· (Gast)
Datum:

Bewertung
-5 lesenswert
nicht lesenswert
> 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.

Autor: Axel Schwenke (a-za-z0-9)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
(º°)·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.· 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.

Autor: Philipp Klaus Krause (Firma: König-Abdullah-Universität) (pkk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael M. 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()
>
> usw. Da konnte ich leider keinen automatismus finden.

#define Serial_print(X) _Generic((X), int: Serial_print_i, char: 
Serial_print_c, float: Serial_print_f)(X)

Philipp

Autor: Michael Mayer (tenbaht)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
// PCD8544 lcd(1,2,3,4,5);  // so wäre es in C++
   PCD8544 (lcd,1,2,3,4,5); // so ist es in C jetzt

setup() {
    lcd_begin();
    lcd_print_s("Hello World!");
}

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:
inline void lcd_inst(void) {
    LCD8544_connection(1,2,3,4,5);
}
inline void lcd_begin(void){
    lcd_inst();
    PCD8544_begin_full(84,48,CHIP_PCD8544);
}
inline size_t lcd_print_s(const char *arg1) {
    return Print_print_s(PCD8544_write,arg1);
}
setup() {
    lcd_begin();
    lcd_print_s("Hello World!");
}
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

Autor: ChrisMicro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hei Micahel, Du bist auf Hackaday:

http://hackaday.com/2017/02/21/smaller-cheaper-arduino/

Autor: Michael Mayer (tenbaht)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ChrisMicro schrieb:
> Hei Micahel, Du bist auf Hackaday:
>
> http://hackaday.com/2017/02/21/smaller-cheaper-arduino/

Danke für den Tipp! Da bin ich ja mal gespannt ob andere Leute damit 
zurecht komme.

Autor: TomFy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
# moved from above so we can find version-dependant ar
ifndef AR_NAME
    ifeq ($(shell expr $(CC_VERNUM) '>' 490), 1)
        AR_NAME      = avr-gcc-ar
    else
        AR_NAME      = avr-ar
    endif
endif

Wenn ich sdcc -v aufrufe, dann bekomme ich als Ausgabe
SDCC : mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8 3.6.5 #9841 (MINGW32)
published under GNU General Public License (GPL)

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
CC_VERNUM = 365
dann läuft das Makefile deutlich weiter. Allerdings endet es wieder mit 
einer Fehlermeldung:
g++ -x c++ -include Arduino.h -MMD -c -I. -I../../sduino//../STM8S_StdPeriph_Driver/inc -I/opt/sdcc/share/sdcc/include/ -mstm8 -DSTM8S103 -DF_CPU=16000000L -DARDUINO=160 -DARDUINO_ARCH_STM8 -D__PROG_TYPES_COMPAT__ -I../../sduino//hardware/sduino/stm8/cores/sduino -I../../sduino//hardware/sduino/stm8/variants/standard     -fpermissive -fno-exceptions -std=gnu++11 -fno-threadsafe-statics -flto blink.ino -o build-stm8sblue/blink.ino.rel
dash: g++: not found

Bin für jede Hilfe dankbar.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier gibst noch eine stm8 Version:
https://dannyelectronics.wordpress.com/2017/05/24/...

Autor: Michael Mayer (tenbaht) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/packa...
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/

Autor: Jan L. (ranzcopter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
bash.exe: warning: could not find /tmp, please create!
...\Arduino15\packages\sduino\tools\sdcc\build.10088/bin/sdcc
...\AppData\Local\Temp\arduino_build_878785\sketch\sketch_nov08a.ino.cpp
...\AppData\Local\Temp\arduino_build_878785\preproc\ctags_target_for_gcc_minus_e.cpp
re12 -c -Ddouble=float -D__PROG_TYPES_COMPAT__ -E -MC -mstm8 -DSTM8S103
-DF_CPU=16000000L -DARDUINO=10804 -DARDUINO_STM8S_BLUE -DARDUINO_ARCH_STM8
-I...\AppData\Local\Arduino15\packages\sduino\hardware\stm8\0.3.1\cores\sduino
-I...\AppData\Local\Arduino15\packages\sduino\hardware\stm8\0.3.1\variants\standard
-I...\AppData\Local\Arduino15\packages\sduino\hardware\stm8\0.3.1/STM8S_StdPeriph_Driver/inc
-I...\AppData\Local\Arduino15\packages\sduino\tools\sdcc\build.10088/include
Mark
re12:...\AppData\Local\Arduino15\packages\sduino\tools\sdcc\build.10088/bin/sdcc
-c -Ddouble=float -D__PROG_TYPES_COMPAT__ -E -MC -mstm8 -DSTM8S103
-DF_CPU=16000000L -DARDUINO=10804 -DARDUINO_STM8S_BLUE -DARDUINO_ARCH_STM8
-I...\AppData\Local\Arduino15\packages\sduino\hardware\stm8\0.3.1\cores\sduino
-I...\AppData\Local\Arduino15\packages\sduino\hardware\stm8\0.3.1\variants\standard
-I...\AppData\Local\Arduino15\packages\sduino\hardware\stm8\0.3.1/STM8S_StdPeriph_Driver/inc
-I...\AppData\Local\Arduino15\packages\sduino\tools\sdcc\build.10088/include
...\AppData\Local\Temp\arduino_build_878785\sketch\sketch_nov08a.ino.cpp -o
...\AppData\Local\Temp\arduino_build_878785\preproc\ctags_target_for_gcc_minus_e.cpp
cpp gefunden
...\AppData\Local\Arduino15\packages\sduino\tools\STM8Tools\2017.11.06/wrapper/sdcc.sh:
line 72: cp: command not found
at 1: error 4: 'fopen' failed on file
'...\AppData\Local\Temp\arduino_build_878785\sketch\sketch_nov08a.ino.c'

...\AppData\Local\Arduino15\packages\sduino\tools\STM8Tools\2017.11.06/wrapper/sdcc.sh:
line 75: rm: command not found
exit status 1
Fehler beim Kompilieren für das Board STM8S103F3 Breakout Board.



Autor: Stefan Us (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Offensichtlich enthält das Makefile einen "cp" Befehl, den müsstes du 
durch "copy" ersetzen, mit den richtigen Parametern.

Autor: Michael Mayer (tenbaht) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jan L. (ranzcopter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/packa...

> 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:
 Cannot run program "ln" (in directory "...\AppData\Local\Arduino15\packages\sduino\hardware\stm8\0.3.2\STM8S_StdPeriph_Driver\src"): CreateProcess error=2, Das System kann die angegebene Datei nicht finden




> testen?
>
>   Michael

Autor: Michael Mayer (tenbaht) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
$ wget https://github.com/tenbaht/sduino/raw/master/package_sduino_stm8_index.json
--2017-11-09 15:56:54--  https://github.com/tenbaht/sduino/raw/master/package_sduino_stm8_index.json
Resolving github.com (github.com)... 192.30.253.113, 192.30.253.112
Connecting to github.com (github.com)|192.30.253.113|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://raw.githubusercontent.com/tenbaht/sduino/master/package_sduino_stm8_index.json [following]
--2017-11-09 15:56:55--  https://raw.githubusercontent.com/tenbaht/sduino/master/package_sduino_stm8_index.json
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.112.133
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.112.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 8990 (8,8K) [text/plain]
Saving to: ‘package_sduino_stm8_index.json’

package_sduino_stm8 100%[===================>]   8,78K  --.-KB/s    in 0,006s  

2017-11-09 15:56:56 (1,44 MB/s) - ‘package_sduino_stm8_index.json’ saved [8990/8990]

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.

Autor: Jan L. (ranzcopter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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";...
ERROR: certificate common name `www.github.com' doesn't match requested host name `raw.githubusercontent.com'.
To connect to raw.githubusercontent.com insecurely, use `--no-check-certificate'.
Unable to establish SSL connection.

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.

: Bearbeitet durch User
Autor: Michael Mayer (tenbaht) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
# check if cp is in the path, add our binaries to the PATH if needed
cp --version >/dev/null 2>&1 || PATH="${0%/wrapper/*}"/win:$PATH
#                                    ^---------------^ die sind neu!

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.

Autor: Jan L. (ranzcopter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
>
>
> # check if cp is in the path, add our binaries to the PATH if needed
> cp --version >/dev/null 2>&1 || PATH="${0%/wrapper/*}"/win:$PATH
> #                                    ^---------------^ die sind neu!
> 

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

C:\Users\jan\AppData\Local\Temp\arduino_build_47110/sketch_nov08a.ino.elf
cmd: C:\Users\jan\AppData\Local\Arduino15\packages\sduino\tools\sdcc\build.10088/bin/sdcc --nostdlib -LC:\Users\jan\AppData\Local\Arduino15\packages\sduino\hardware\stm8\0.3.2/STM8S_StdPeriph_Driver/lib -LC:\Users\jan\AppData\Local\Temp\arduino_build_47110 -LC:\Users\jan\AppData\Local\Arduino15\packages\sduino\tools\sdcc\build.10088/lib/stm8 --code-size 8192 --iram-size 1024 -mstm8 -DSTM8S103 C:\Users\jan\AppData\Local\Temp\arduino_build_47110\sketch\sketch_nov08a.ino.c.rel C:\Users\jan\AppData\Local\Temp\arduino_build_47110\sketch\sketch_nov08a.ino.cpp.rel C:\Users\jan\AppData\Local\Temp\arduino_build_47110/..\arduino_cache_183954\core\core_sduino_stm8_stm8sblue_7eb4e10c40551a355ebadbfb050b10cd.lib C:\Users\jan\AppData\Local\Temp\arduino_build_47110/core/main.c.rel -lSTM8S103 -lstm8 --out-fmt-elf -o C:\Users\jan\AppData\Local\Temp\arduino_build_47110/sketch_nov08a.ino.elf
Multiple definition of _led

Multiple definition of _setup

Multiple definition of _loop

exit status 1
Fehler beim Kompilieren für das Board STM8S103F3 Breakout Board.

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

Autor: Jan L. (ranzcopter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Michael Mayer (tenbaht) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
# not need, but gives us lots of debug information
set -x
# check if cp is in the path, add our binaries to the PATH if needed
echo "vorher: $PATH"
cp --version >/dev/null 2>&1 || PATH="${0%/wrapper/*}"/win:$PATH
echo "nachher: $PATH"

Was könnte bei Dir anders sein und Probleme machen? Ein Versuch wäre 
noch, export einzufügen (sollte aber keine Rolle spielen):
cp --version >/dev/null 2>&1 || export PATH="${0%/wrapper/*}"/win:$PATH


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

Autor: Michael Mayer (tenbaht) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Jan L. (ranzcopter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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! :-)

Autor: Michael Mayer (tenbaht) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Michael Mayer (tenbaht) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So klappt es mit der automatischen Pfadanpassung bei mir:
# 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?

Es bleibt aber die Grundfrage, wie der überhaupt auf die Idee kommt, 
ausgerechnet STM8Tools als root zu verwenden.

Autor: Jan L. (ranzcopter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>
> 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:...

Autor: Jan L. (ranzcopter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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... ;-)

Autor: Jan L. (ranzcopter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Jan L. (ranzcopter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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... :)

Autor: Michael Mayer (tenbaht) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
# check if cp is in the path
if ! command -v cp > /dev/null; then
        # Alternative 3: Geht zumindest bei mir.
        cd "${0%/wrapper/*}"
        PATH=$(pwd)/win:$PATH
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?
        # Alternative 1: geht bei mir, bei Dir aber nicht (Warum?):
        PATH="${0%/wrapper/*}"/win:$PATH

        # Alternative 2: Eigentlich falsch, klappt unter Windows aber trotzdem:
        cd $0/../..
        PATH=$(pwd)/win:$PATH

Wenn das so klappt, kann ich morgen ein update fertig machen.

Autor: Jan L. (ranzcopter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
>
>
> # check if cp is in the path
> if ! command -v cp > /dev/null; then
>         # Alternative 3: Geht zumindest bei mir.
>         cd "${0%/wrapper/*}"
>         PATH=$(pwd)/win:$PATH
> fi
> 

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?
>
>
>         # Alternative 1: geht bei mir, bei Dir aber nicht (Warum?):
>         PATH="${0%/wrapper/*}"/win:$PATH

funktioniert nicht
(war ja irgendwie system-root != bash-root...)

> 
>         # Alternative 2: Eigentlich falsch, klappt unter Windows aber 
> trotzdem:
>         cd $0/../..
>         PATH=$(pwd)/win:$PATH

Ja, die 3. Version von Dirty Harry tut's auch! ;)

Wobei ich eigentlich finde, dass die Variante aus
https://www.mikrocontroller.net/topic/sduino-beinahe-arduino-fuer-stm8s#5204792
(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. 


> 
>
> Wenn das so klappt, kann ich morgen ein update fertig machen.

: Bearbeitet durch User
Autor: Michael Mayer (tenbaht) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Jan L. (ranzcopter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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? :)

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.