Diskussions- und Newsboard des DARC-Ortsverbandes I40
allgemeine Kategorie => UHSDR Firmware => Message started by: DF8OE on 11. July 2019, 08:02:16

Title: Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 11. July 2019, 08:02:16

Wer UHSDR unter Linux bauen möchte findet hier wichtige Infos.

Ich möchte aber (weil ich auch in Sachen Linux ein Projekt laufen habe - eine LIG Linux Interessen Gruppe) hier wirklich nur UHSDR-spezielle Fragen beantworten. Wer Tipps, Infos und Hilfe zu Linux allgemein möchte den möchte ich auf mein Linux-Forum (https://www.suletuxe.de/forum/index.php) verwisen. Ich möchte Synergieeffekte ausnutzen...

Linux ist nicht nur als Entwicklerplattform für Funkamateure interessant - auch die Tatsache, dass (wenn man die richtige Distribution wählt) sehr viele Amateurfunk-relevante Programme in brandaktuellen Versionen bereits in den Repositories vorhanden sind und nicht aus verstreuten Ecken des Internets selbst zusammengesucht und installiert werden müssen ist ein wichtiges Argument für Linux. Sind Programme in den Repositories dann bekommt man automatisch Updates bei Fehlerbereinigungen und neuen Features - ganz bequem...

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 12. July 2019, 05:55:15

Wen Du Fragen oder Probleme mit Arch Linux hast helfe ich Dir hier (https://www.suletuxe.de/forum/index.php) gerne weiter...

Arch besticht im Vergleich mit anderen Distributionen durch

  • hochaktuelle Software (so ist dort der Kernel 5.2.0 im Einsatz)
  • es ist eine "Rolling Release" (es gibt also niemals einen Versionssprung der nach sich ziehen würde, dass Du entweder eine Upgrade-Orgie oder eine Neuinstallation machen musst)
  • täglich (!!) Bugfixes und neue Features

  • Allerdings ist etwas Umstellung in der Denkweise des Paketmanagements notwendig wenn man von Debian kommt. So muss man z.B. die AURs aktivieren (Arch User Repositories) um den vollen Softwareumfang zu bekommen.

    vy 73
    Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 12. July 2019, 06:31:46

Du wirst die gleichen Binary-Größen erreichen wie die aus unserem Binary-Downloadbereich. Je nach Toolchain (aktuell ist in Arch noch die von Ende letzten Jahres die neueste aber ich denke es kann nur noch Tage dauern dann ist die vom 10. Juli in den Repositories verfügbar) schwankt das um ein paar Kilobytes. Bie der Firmware ist das sicherlich unbedeutend, beim Bootloader kann das entscheidend sein, denn wir kratzen sehr stark an der 32KB-Grenze beim F4 und beim F7 (beim H7 ist aufgrund einer anderen Aufteilung des Flashspeichers keine 32KB-Begrenzung).

Bei Arch gibt es das zentral gepflegte Repo (wie bei Debian) - das ist aber wesentlich kleiner als bei Debian. Es umfasst etwa 20% des Debian-Repos. Zusätzlich können einzelne Entwickler ihre tollen Projekte (nach passieren diverser Schutzmechnismen) auch direkt anbieten und pflegen - das erfolgt in den AURs. Dort liegen die Programme nicht als Binaries vor, sondern meistens im Quellcode (!!). Unter Arch gibt es Helperprogramme wie "yay". Diese installieren Dir Programme aus den AURs wie aus den Hauptrepos. Dabei wird der Quellcode heruntergeladen, dann kompiliert und im Abschluss ein installierbares Paket gebaut das dann installiert wird. Das alles findet auf deinem eigenen Rechner statt - automatisch! Die Möglichkeiten, die sich dadurch einem erfahrenen User bieten, sind sehr vielfältig, und der Anfänger braucht es nicht zu verstehen, weil es ja automatisiert abläuft. Nur brauchst Du um die AURs nutzen zu können noch ein paar Programmpakete - vorher "siehst" Du die AURs gar nicht ::)

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 12. July 2019, 06:51:16

Hier muss ich meine "speziellen Projekte" berücksichtigen, die ALLE vorankommen sollen und müssen. Und eines davon ist eine LIG (Linux Interessen Gruppe). Dieser Gruppe die (gemessen an der amateurfunk-sulingen Gruppe) noch ganz am Anfang steht möchte ich keine Inhalte entreißen.

Ich denke dass die Probleme rund um das Bauen von UHSDR hier in diesem Board richtig untergebracht sind. Sollten sich tatsächlich mehr Leute finden, die mal in Linux reinschnuppern wollen, würde ich diesen Support aber gerne im Bereich meiner LIG geben - dann sind die Synergieeffekte größer. Also für mich klare Trennung nach "UHSDR-bezogen" und "allgemein Linux bezogen".

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 13. July 2019, 17:12:47

Eben gerade ist die Toolchain vom 10.07. in den Repos von Arch Linux aufgetaucht. Hat knappe drei Tage gedauert.

Bei Debian wird das Monate - vielleicht auch länger als ein Jahr dauern bis die da in den Repos ist...

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 14. July 2019, 07:56:03

Ich habe natürlich auch eine grafische Oberfläche - und in die bootet das System sogar "default" ::)

Da ich Linux-Komplettsysteme auch zum Verkauf anbiete (https://www.come-2-linux.de) habe ich sogar ein System zusammengestellt, dass sehr viele verschiedene grafische Oberflächen hat wie KDE, Gnome, Cinnamon, Mate, LXDE, Xfde, Tde und etliche mehr...

Persönlich arbeite ich mit dem KDE. Wenn ich eine (oder meistens gleich mehrere) Konsolen brauche mache ich sie mir einfach in einem Fenster auf. Dann können die anderen Anwendungen gleichzeitig im Blick bleiben.

Bislang habe ich die Distribution "Antergos" genommen. Das war (muss ich leider sagen) ein Arch mit einem schönen grafischen Installer - leider wurde das Projekt im Mai beendet. Aber wie Phönix aus der Asche (das ist bei Open Source normal) entsteht gerade jetzt der Nachfolger, der es dem Anfänger wieder leicht macht, ein schickes Arch zu installieren: https://endeavouros.com .In den nächsten Tagen wird released. Mich interessiert das nur am Rande, weil meine Systeme, die ich anbiete, im Laufe von Jahren "gewachsen" sind und ich diese Images für eine Installation verwende...

Das WIKI von Arch ist ganz ausgezeichnet - die Community ist eher nicht so nachtragend bei DAU-Fragen. Da war die Antergos-Community toleranter, und genau die wird in EndeavourOS wiederzufinden sein.

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 14. July 2019, 10:08:57

Bei mir ist im Jahr 2000 der Hebel umgelegt worden. Damals stand ich (mal wieder) vor einer Neuinstallationsorgie von Windows (gefühlt die 5. innerhalb eines Monats) und ich bin zu der Entscheidung gekommen, lieber meine Energie in etwas zustecken was von Dauer ist und mir nicht ständig den Geldbeutel und mein Zeitkonto belastet als die x. Windows-Neuinstallation zu machen. Sicher waren die Anfänge damals noch schwieriger als heute (es gab keinen wirklich anfängertauglichen Installer, vieles MUSSTE man auf der Konsole machen - kein grafisches Tool dafür da) etc. - aber ich habe mich durchgebissen und die Entscheidung niemals bereut. Seit 2000 mache ich ALLES - egal ob beruflich oder privat - nur noch mit Linux. Auf meinen Smartphones und Tablets läuft LineageOS und ein Apfel, Fenster, eine Alexa oder Siri, ein Ipad oder Iphone kommt mir nicht ins Haus (auch nicht wenn ich Geld beigelegt bekomme)... Ich habe mit SuSE 4.6 begonnen, bin dann 2004 zu Ubuntu gewechselt, und als mir das wieder zu Mainstream und in eine (Unternehmer-)Richtung abgewandert ist bin ich bei Debian selbst gelandet. Zuerst "Debian Stable", dann weil mir auch hier die Versionssprünge mit Updates eines gesamten Systems alle paar Jahre auf den Senkel gegangen sind zu "Siduction" (das ist eine Rolling Release basierend auf "Debian experimental), und als mir selbst da die Softwarepakete zu alt waren seit etwa 9 Monaten bei Arch.

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 15. July 2019, 04:09:29

Du stehst vor einem leicht lösbaren Problem, weil Du
1) genau angezeigt bekommst was nicht funktioniert
2) es unter Linux einfache Möglichkeiten gibt das vorliegende Problem mit ein oder zwei Kommandozeilenbefehlen zu beheben.

Unter Windows gibt es für 99,9% "Automaten", die es auch jemanden völlig ohne Sachkenntnisse ermöglichen es zu nutzen. Diese Automaten gibt es unter Linux nicht und genau das ist der Grund warum ich es jedem Windows (oder MacOS) vorziehen würde. Ich will bestimmen und wissen was da passiert - das soll weder Microsoft noch Apple tun.

Ich würde jetzt folgendes tun:
1) zu "root" werden
2) mit "ifconfig" die Netzwerkdevices anzeigen lassen

Sind alle da - oder nur das "lo"? Wenn nur letzteres da ist fehlt deine "eigentliche Netzwerkkarte". Die heißt in einem System das auf realer Hardware läuft "enp..." (da kommen noch ein paar Zeichen hinter). In einer Windows-VM hatte ich sowas logischerweise noch nie laufen.

Fehlt das Netzwerkdevice, kannst Du alle (auch die inaktiven) mit "ifconfig -a" anzeigen lassen. Und wenn dann das richtige Netzwerkdevice zu sehen ist kannst Du es mit "ifconfig <Name des Devices> up" aktivieren. Dann nochmal mit "ifconfig" nachschauen, ob es jetzt da ist (und auch eine IP-Adresse zugewiesen bekommen hat). Wenn nicht, muss noch geklärt werden wie das Netzwerkdevice seine IP-Adresse bekommt (DHCP?)

Ohne Fachwissen ist man in meinen Augen nicht in der Lage, ein Betriebssystem zielgerichtet und ohne Neuinstallation (!!) zu warten oder reparieren. Sich auf Automaten zu verlassen ist in meinen Augen keine Lösung. Mit Closed Source und Automaten ist man nicht in der Lage zu beurteilen was alles in deiner "Büchse der Pandora" noch so werkelt was Du gar nicht haben willst. Und Du bist meistens nicht in der Lage in die Funktion der Automaten einzugreifen und etwas anderes zu tun als der Automat will. Der will "meistens" das was Du willst - aber je ausgefallener deine Ansprüche sind desto öfter willst Du eben doch was anderes.

Das ist der Punkt an dem man lernen muss zu verstehen was das alles ist, wie es zusammenhängt und wie man wirklich Herr seines Systems wird. Die ersten 4 Wochen sind sehr hart, dann geht es schon leichter, und nach einem Vierteljahr ist man (bei täglicher Nutzung) schon recht gut drauf.

Wenn man das nicht investieren will ist man bei Linux in der Tat falsch. Ohne Grundverständnis (und das muss man auch bei jahrzehntelanger Nutzung von Windows lernen weil man es da weder braucht noch bekommt) geht gar nichts. Mit Grundverständnis hast Du aber den "Turbo" in der Hand und holst aus dem System Sachen raus wo andere noch nicht mal verstehen was Du da machst ::)
Es hat jeder selbst in der Hand welchen Weg er gehen will.

Würde ich nicht so denken wäre ich nicht an die Sache rangegangen, meine RF-Platinen mit FPGAs zu bestücken - es fehlte ja das Grundwissen...

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 15. July 2019, 04:32:55

Nachtrag:

Da ich seit 17 Jahren erfolgreich Linux in meinem näheren Bekanntenkreis verbreite und das auch beruflich nutzen wollte kenne ich natürlich das Henne/Ei-Problem:
Du kannst Dir kein wirklich gutes System selbst installieren (Ubuntu ist wesentlich einfacher - aber kommt mittlerweilen auch irgendwie aus dem Hause Microsoft und trägt auch schon etliche überflüssige Automaten und Telemetriesender in sich) weil Dir die Grundkenntnisse fehlen und hast so von Anfang an Frustration. Diese Lücke habe ich mit meinem Geschäftsmodell "come-2-linux" geschlossen: Es gibt ein komplett vorinstalliertes System von mir auf dem jede Menge zusätzlicher Software und viele verschiedene grafische Oberflächen gleich mit drauf ist - und dieses System läuft auf so gut wie jeder Hardware wo Du sdie Platte anschließt ;D. Dann kann man den ersten Schritt sozusagen überspringen und gleich loslegen.

Besser ist/wäre es wenn man sich die Zeit nimmt und Geduld mit sich hat es sofort selbst zu verstehen und zu lernen. Ist aber nicht jedermanns Sache.

Es gibt nichts umsonst auf der Welt. Entweder man bezahlt mit Geld oder man bezahlt mit seiner Zeit und einer gewissen Anstrengung.

Wenn man mit Geld bezahlt hat man den Vorteil dass man es sofort bekommt und sich nicht groß bewegen muss (Bequemlichkeit first). Man hat aber den Nachteil dass man es auch in Zukunft kaum anders lösen kann als mit Geld: man kommt in Abhängigkeit und wird im Grunde unglücklich, weil man ständig Geld in die Hand nehmen muss und keine Erfolgserlebnisse bekommt.

Wenn man den anderen Weg geht muss man seinen inneren Schweinehund überwinden und zahlreiche Scheinargumente die in einem kreisen erstmal besiegen ("ich habe keine Zeit", "das kostet mir zuviel Mühe", "ich habe es ja vorher gesagt: alles Mist dieses Linux alles kryptische Befehle"). Dann muss man ein gewisses Durchstehvermögen haben und bereit sein vieeel zu lernen. Als Vorteil wird man wenn man den Weg erfolgreich gegangen ist etwas besitzen, was einem keiner mehr wegnehmen kann. Das man für sich selbst, für seine Freunde und Bekannten und für jeden anderen weiterbringend anwenden kann. Und so ganz nebenbei hat man die Basis dafür gelegt, immer mehr Details bei seinen Tauchgängen zu erkennen die man vorher weder gesehen noch erwartet hat...

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 15. July 2019, 05:03:41

Das Problem das Du da hast ein ganz spezielles - das kann ich schonmal sagen. Denn gerade die Netzwerksachen laufen bei Linux echt gut. Es wird nicht so sehr mit Linux als vielmehr mit deiner VM zusammenhängen. Das dort zur Verfügung gestellt Device verhält sich einfach nicht wie sich eine Standard-Netzwerkkarte verhalten sollte und deswegen läufst Du auf Grundeis.

Was Du jetzt machst und suchst ist ein Workaround für das Problem dass sich die Netzwerkkarte nicht so verhält wie sie es sollte.

Wenn ich die Ausgaben von "ifconfig" und "ifconfig -a" sehen würde wüsste ich mehr...

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 15. July 2019, 05:38:16

Hallo Thomas,

...und da sind sie schon, die ersten fehlenden Grundkenntnisse - aber da kann ich helfen 8)

Eine VM ist eine "virtuelle Hardware". Es wird dem zu installierenden Betriebssystem eine Hardware "vorgegaukelt", die es gar nicht gibt. Dein zu installierendes System "sieht" also eine CPU, RAM, eine Grafikkarte und auch eine Netzwerkkarte. Diese Netzwerkkarte ist aber REINE SOFTWARE - sie ist nicht identisch mit deiner Netzwerkkarte, die Du real in deinem Rechner stecken hast! Diese virtuelle Netzwerkkarte stellt eine Bridge zu deinem über die echte Netzwerkkarte laufenden Netzwerk her.

Offenbar erhältst Du die IP-Adresse via DHCP - das ist schön und es ist auch schön dass das funktioniert wenn Du es manuell anstößt. Vielleicht wurde bei der Installation einfach nicht korrekt erkannt dass Du deine Netzwerkinfos über DHCP bekommst und der Dienst "DHCP-Client" wurde nicht so angelegt dass er bei einem Neustart automatisch läuft? Da würde ich jetzt zuerst nach googlen (ich will Dir ja nicht die Lösung zum Abtippen schreiben...)

EDIT:
Fehlende Grundkenntnisse sind nicht schlimm - denn was fehlt, kann man ja "nachrüsten". Ich bin gerne bereit, alle möglichen Fragen zu beantworten - wenn ich (wie in diesem Fall) die nötigen Angaben ("was habe ich selbst schon versucht?") bekomme. Das sind alles winzige Bauklötze die dann zu einem Gebäude wachsen wenn man genug davon gelernt hat...

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 15. July 2019, 06:06:05

8)

Das ist der richtige Weg.

Übrigens gleich eine wichtige Info vorweg: eine "Neuinstallation" beseitigt nur Probleme, die man selbst verursacht hat (indem man an Stellen etwas verändert hat an denen man besser nichts verändert hätte) oder Probleme die irgendwelche nicht nachvollziehbaren Automatenaktionen als Ursache hatten. Ersteres wäre ein Grund für eine Linux-Neuinstallation (aber man kann sich selbst erinnern ob man irgendwas getan hat was man nicht verstanden hat und was man nicht rückgängig machen kann), letzteres ist der Hauptgrund für Neuinstallationen kommerzieller Betriebssysteme. Durch die fehlende Intransparenz hat man meistens keine Chance (mit noch so viel Grundwissen) den Fehler zu finden weil man nicht weiß was der Automat gemacht hat und tiefe Einblicke in die Funktionsweise oft vernagelt sind.

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 15. July 2019, 09:20:47

:D.

Sehr schön. Plasma ist eine schöne Oberfläche.

Wenn Du Probleme hast und selbst keine Lösung in akzeptabler Zeit (30 Minuten würde ich sagen) gefunden hast --> frag!

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 15. July 2019, 09:55:45

Wenn Du "leightweight" willst empfehle ich Dir den Xfce oder den LXDE.

Aber Obacht:
nicht alle Desktops "vertragen sich"!! Diese drei würden es tun. Für viele Kombinationen musste ich zu Tricks greifen: da werden beim Einloggen die Libs symbolisch dazugelik#nkt mit denen die betreffende GUI läuft und alle sind parallel vorhanden. Nichts für Anfänger...

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 15. July 2019, 12:50:11

Ich denke das gehört noch ins Afu-Forum... Es geht um UHSDR kompilieren.

1) Du musst den Support für die AURs aktivieren (Arch User Repositiries)
2) installiere danach yay
3) Dann installierst Du mit
yay -S arm-none-eabi-gcc
(als User ausführen!!)
die Toolchain. Es ist die vom 10.07.

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 15. July 2019, 13:19:57

Das sind die Dinge die wir auf unseren Treffen lernen und gleich am Notebook nachmachen können...

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DB4PLE on 15. July 2019, 15:01:48

Hallo,

wenn Ihr da so toll dabei seid, vielleicht integriert ihr dieses Wissen mal ins Wiki. Da gäbe es noch Platz in der Seite fürs Aufsetzen der Firmware-Dev-Umgebung auf Arch Linux .

;)

73
Danilo

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 15. July 2019, 15:19:01

Das müsste ein "Teamwork" werden. Mein Arch Linux ist ja schon seit langem komplett und auch anders entstanden (via Antergos) als es das über Arch direkt geht. Aber wenn Thomas die nötigen Seiten erstellt lese ich natürlich gerne quer und ergänze oder korrigiere falls nötig...

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 15. July 2019, 15:23:52

Es ist das GitHub-WIKI gemeint... Wobei die Markdown-Language recht ähnlich ist (eben WIKI...)

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DB4PLE on 15. July 2019, 16:10:06

Genau.

Und das GitHub-Wiki ist hinreichend einfach zu bedienen, insbesondere wenn man nur auf einer Seite ein paar Sachen aufschreiben will. Vielleicht schaust Du ja mal vorbei https://github.com/df8oe/UHSDR/wiki/Setting-up-Firmware-Development-Software (https://github.com/df8oe/UHSDR/wiki/Setting-up-Firmware-Development-Software)
Quote from: DF8OE on 15. July 2019, 15:23:52
Es ist das GitHub-WIKI gemeint... Wobei die Markdown-Language recht ähnlich ist (eben WIKI...)

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 15. July 2019, 20:46:57

Dir fehlt noch eine Arm Standard Library. Steht im GitHub-Wiki und ist bei Arch selbstverständlich in den Repos.

Hast Dich gut durchgebissen!!

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 16. July 2019, 03:57:52

...übrigens ist bei Arch Linux auch Eclipse in den Repositories. Natürlich ebenfalls mit der aktuellsten Version ;D. Damit könntest Du dann auch die grafische Umgebung dort hinlegen.

Da die Config so ausgelegt ist dass sie auch unter Windows läuft unterliegt sie aber den Beschränkungen von Windows - und ist beim Bauen genauso groß wie mit Windows.

Man könnte die Config speziell für Linux anpassen, dann wären die Binaries genauso klein wie beim make - Bau - aber wir wollen nicht zwei Configs pflegen müssen. Geht doch mit make!

Und wenn man die "richtige Distribution" wählt hat man auch keine Probleme mit der Aktualität der in den Repos vorhandenen Software...

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 16. July 2019, 04:51:47

yay ist ein vollständige Ersatz für pacman. Es kennt auch die gleichen Parameter wie pacman (und ein paar mehr). Für Dich wichtigster Unterschied: pacman arbeitet nur mit den "normalen" Repositories, yay tut das und arbeitet zusätzlich mit den AURs (Arch User Repositories). Den Befehl "pacman" kannst Du in deiner Erinnerung begraben - Du wirst ihn nie wieder brauchen wenn Du yay hast.

Wichtiger Unterschied:
pacman muss als "root" laufen
yay darf nicht als "root" laufen

Grund:
yay baut auch Software aus den Quellen. Aus Sicherheitsgründen geschieht das Bauen IMMER ALS USER. Nach dem Bauen erstellt yay ein installierbares Paket (so wie eines das pacman direkt aus den Repos runterlädt) und erst jetzt, wo das Paket installiert werden soll, fordert yay für sich "root-Rechte" (via sudo).


pacman installiert ja nur - also alles und immer als "root"
yay baut auch - also bauen als User und installieren: siehe pacman.


EDIT:
Und natürlich bietet Eclipse Vorteile: beim Debuggen. Du kannst den ST-Link beim Laufen der Firmware angeschlossen lassen und "life debuggen". Das geht auf der Konsole zwar auch - ist aber doch sehr umständlich im Gegensatz zur integrierten Debugging-Schnittstelle in Eclipse.

Zum Programmieren der FW auf die UI brauchst Du dann noch die beiden Pakete
dfu-util (Kommandozeilenersatz für den STM dfu)
st-link (Kommandozeilenersatz für das ST-Link-Utility)


vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 16. July 2019, 05:11:53

Ja, Linux hat ein ausgefeiltes und funktionelles Rechte-System. Da gibt es feine Abstufungen und alles was Du zur Anpassung machen musst ist Konfigurationsdateien bearbeiten, die alle Textdateien sind! Zur Bearbeitung empfehle ich Dir den "midnight commander", der alten DOS-Hasen als "Norton Commander" bekannt sein dürfte. Du installierst ihn mit

yay -S mc

und rufst ihn auf mit

mc

Vorteil: Klein, schnell, läuft auf der Konsole (also für mich "läuft auch unter ssh"), leicht zu erlernen. Den benutze ich oft zum Programmieren. Und auf zwei anderen Konsolen habe ich dann noch find, grep und sed am Start. Damit kann ich dann z.B. in allen Quelldateien nach irgendeiner Funktion oder Variablen suchen während auf de anderen Konsole meine bearbeitete Quelldatei noch offen ist. Oder auch auf mehreren Konsolen mehrere Quelldateien - je nach Lust und Laune.

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 16. July 2019, 07:58:51

Richtig - das war falsch 8)

Aber der Bau des Paketes hat ja sowieso nicht geklappt - also egal.

Du brauchst

gcc-arm-none-eabi-bin

Das von Dir installierte

arm-none-eabi-binutils-2.32-1-x86_64
und
arm-none-eabi-gcc...

wird dann hoffentlich automatisch wieder deinstalliert. Wenn nicht: händisch machen.

EDIT:
Alles was Du in deinem letzten Post geschrieben hast (hat sich mit meinem überschnitten) brauchst Du nicht.

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DB4PLE on 16. July 2019, 10:16:45

Hallo Thomas,

BITTE NICHT das Makefile ändern!

Um für den H7 zu kompilieren, kannst Du ganz einfach die richtigen Parameter make mitgeben:


Code:

make BUILDFOR="H7" TRX_ID="i40h7" TRX_NAME="OVI40H7" CONFIGFLAGS="-DUI_BRD_OVI40 -DRF_BRD_MCHF -DRF_BRD_OVI40" all


Die Datei .travis.yml im UHSDR Verzeichnis ist da eine Quelle der Inspiration. Insbesondere wenn man mehrere Builds (F4/H7 bootloader und firmware) machen will, empfiehlt es sich mit build-Verzeichnisssen pro build zu arbeiten und nicht direkt im Source zu bauen. Dafür sind dann -f ... und ROOTLOC zu verwenden:

Ins build Verzeichnis gehen
Hinter -f der Pfad zum Makefile
und ROOTLOC ist der Pfad zum Verzeichnis in dem das Makefile ist.

Dafür muss man keine $... Variablen verwenden so wie im Skript, das kann man auch direkt dort angeben. Im Skript ist es mit Variablen aber einfacher...

73
Danilo

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 16. July 2019, 13:10:00

Festplatte voll == "no space left on device" 8)

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 16. July 2019, 13:49:40

Du könntest auch den cache für installierte Pakete löschen - da sind auch leicht ein paar hundert Megabytes bis Gigabytes belegt...

yay -Sc --noconfirm

und dann noch:

sudo paccache -vrk0

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DL2GMI - Michael (H44MI) on 16. July 2019, 17:58:20

Kleiner Tip von mir:
Um zukünftig alle Platz- und Hardwareprobleme einer VM ausschliessen zu können: Besorg dir einen gut erhaltenen PC oder ein gut erhaltenes Notebook und pack da nur Linux drauf. Glaube mir - irgendwann willst du nicht mehr mit Windows arbeiten.

(ich habe damals mit SuSe Linux 5.2 angefangen....)

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DB4PLE on 16. July 2019, 18:48:59

Hallo,

zu diesem Thema: Wer einen GitHub Account hat, kann jetzt in 20s eine funktionierende Buildumgebung haben, wenn er oder sie mittels des GitPod Dienstes eine virtuelles Linux im Browser startet. Andreas hat gerade meinen Pull Request auf GitHub akzeptiert.

Einfach die Anleitung von mir hier befolgen:

https://github.com/df8oe/UHSDR/blob/active-devel/CONTRIBUTING.md#getting-started

Das sind nur ein paar Klicks und schon kann man Make bei der Arbeit zuschauen....

Probiert es mal aus!

Hinweis: Ich bin nicht von der Firma hinter Gitpod gesponsort, und behalte gerne die Kontrolle über meine Daten, aber bei einer Arbeit an einem Open Source Projekt kann man das schon mal so machen, wenn man keinen passenden Rechner zur Hand hat oder an der Installation verzweifelt...

73
Danilo

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DL6KL on 16. July 2019, 19:29:00

Hallo Thomas.
Habe heute mal das erste Script , das englische, ausprobiert.
Bin bis zum Reboot gekommen, danach wird immer wieder die Installation CD angefordert.
Startet nicht von alleine um weiter zu machen.
Habe ich da was übersehen?
Bis zumRebootist alles ohne Fehlermeldung gelaufen
Gruß

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DB4PLE on 16. July 2019, 19:59:53

Hallo Thomas,

dann kann ich ja davon ausgehen, dass meine Anleitung verständlich war ;)

Ich sehe das auch eher als Ergänzung. Für ernsthafte Entwicklung und vorallem Debugging ist das ganze (noch) nicht tauglich, da ist eine ausgewachsene IDE (die man dann auch noch beherrschen muss) deutlich besser. Bei mir ist das halt Eclipse.

Aber für eine kleine Änderung oder Idee tuts auch Gitpod vom Smartphone oder Tablet.

73
Danilo

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 17. July 2019, 06:07:08

Mit GitPod "erspart" man sich nicht Linux - Gitpod ist Linux! Man spart sich nur "lernen" und "verstehen" - Hauptsache das Ergebnis stimmt. Wenn man nur mal ab und zu ein Binary bauen will ist das sicher die richtige Lösung - aber man ist abhängig.

Microsofts (und GitHub gehört ja jetzt Microsoft) Geschäftsmodell ist, alle computertechnischen Dinge so sehr zu automatisieren dass man ohne irgendwas davon zu verstehen Mainstreamaufgaben mit dem PC erledigen kann. Auch Apple beherrscht das sehr gut.

Ich bin mir nur noch nicht sicher ob wir ein Henne/Ei-Problem haben und falls ja was die Henne und was das Ei ist:

- erst sanken Grundwissen und Intelligenz ständig ab und daraufhin passte Microsoft seine Software an
oder
- dadurch dass man bei Nutzung stark automatisierter Software nicht mehr nachdenken musste verkümmerten Grundwissen und Intelligenz

Mit viel Humor auch im Film "Idiocracy" nachzuvollziehen...

Der nächste Schritt wird dann von Google vollzogen: wenn selbst das Bewegen der Maus und das Aussuchen des "richtigen" Menüpunktes zu schwierig wird muss eine Lösung her bei der man es mit "wischen auf einem Touchscreen" erledigen kann ::)

Aktuell ist es auf jeden Fall so das jeder selbst entscheiden kann welchen Weg er gehen will. Dass alles was wir tun Folgen für uns hat (und auch das was wir nicht tun hat Folgen für uns) ist ja logisch!

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: SP9BSL on 17. July 2019, 07:53:56

Quote from: DL8EBD on 17. July 2019, 06:26:57
Vieles musste erst gelernt werden....und das fast ausschließlich Abends nach Feierabend wenn die Aufnahmefähigkeit nahe null ist.


And then your curiosity/ambition must win with your tiredness/home duties/family etc... Everyone of us work this way - it's hobby. Anyway good luck with your way of learn, any hands on UHSDR board are welcome :)

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DB4PLE on 17. July 2019, 08:55:36

Hi,

In a nutshell my credo:

Programming itself, especially in a collaborative project, is difficult enough, I don't want to be bothered with spending days to setup the development environment for a project. Glad if someone else does most of this work for me.

Of course at least one person needs to be "in charge" for this so that others can benefit from their work.

73
Danilo



Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: SP9BSL on 17. July 2019, 09:25:19

hmm.. controversial question: if I use Windows machine and setup of whole IDE on fresh machine took me about 30min, what is the advantage to me to bother with linux? (I would admit that we use Travis to check if it builds under linux anyway)

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 17. July 2019, 11:28:22

In short: Everyone can feel free to choose "his own way".

My history with Windows is a very bad one and I never would come back to it. But that is only MY opinion.

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: SP9BSL on 17. July 2019, 18:12:27

Hi Andreas,
the intention of my question was not to degrade the Linux itself nor promote Windows, I meant rather: is there any advantage for me to switch to Linux (it doesn't matter VM or pure system install) for UHSDR development? I have enough machines to go this way, but I'm just curious if IDE/build/debug works better (faster) under Linux?

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DB4PLE on 17. July 2019, 18:40:08

Hi,

although I did not test this on Linux I would dare to say, that Eclipse is Eclipse is Eclipse. So an Eclipse build won't go much faster on Linux. CDT tends to waste some time when compiling. Don't know why.
EDIT START:
I just tested the external builder in Eclipse 2018-12 with the most recent GNU MCU Eclipse plugins installed, and the build runs as fast as the makefile build on the same machine. Especially the start of compilation was instantaneous, which was previously a big issue with the external builder. The internal builder is a lot slower since it cannot run multiple compiles in parallel (the external build has no problem with this).

Eclipse External Builder: 1m:50s (DSPLib build not included, parallel build)
Eclipse Internal Builder: 3m:07s (DSPLib build not included, single processor)

Single .c file changed build: 27s (internal and external same time).

This is a i5 4300U processor
Conclusion: No relevant difference anymore to a command line build in a typical scenario.
:EDIT END

It is a little easier to get the makefile build going on a typical Linux Distribution. And make does used to build a lot faster than Eclipse. But debugging, code navigation and refactoring is so much more comfortable with Eclipse compared to the command line tools (no matter if on Linux or Windows)...

I think, we have a pretty simple setup on Windows. I just recently set a new PC up to compile UHSDR and it was not a big deal.


73
Danilo


Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: SP9BSL on 17. July 2019, 20:07:28

Hi Danilo,
thank you for this explanation.
We discussed some time ago the ability to enable the parallel build under eclipse, unfortunately nothing changed since then. I use Atolic in work and there parallel build always works, under SW4STM32 sometimes have issues thus I had to disable it (anyway I use it only for old projects because Atolic is now free). I do not know what Atolic team changed in Eclipse but their customized version works perfect out of the box.

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DB4PLE on 17. July 2019, 20:21:18

Hi Slawek,

as I said, in the newest GNU MCU Eclipse (which is basically Eclipse 2018-12) the Eclipse "CDT external builder" works perfectly and we can make it the default. Why the Eclipse internal builder is too stupid to detect that it should first wait until all files are compiled and only then starts the linker is beyond me. In any case, it seems that finally the external builder was fixed and is now really fast. Probably the Atollic team fixed that long ago but did not publish the changes (which they don't have to under the Eclipse Public License).

For those having no idea what we are talking about:
Eclipse has different ways to build C programs: It can internal calculate the necessary compile steps and calls the compiler directly. This is called the "Internal Builder". The "External Builder" is call external, because Eclipse generates first the necessary Makefiles from the project information and hands over the actual compile to the external "make", which then runs the previously generated makefiles.

For those wondering: Eclipse can also use hand-written Makefiles but then a lot of the convenience of Eclipse goes away. This is another build mode again in which neither the "Internal Builder"or "External Builder" is used...

73
Danilo



Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 31. July 2019, 05:20:50

Außerdem habe ich ein kleines Bash-Script geschrieben das mir mit einer kleinen Oberfläche im Terminal

  • wahlweise mehrere Bootloader / Firmwareversionen automatisch nacheinander baut
  • die Versionen hochzählt
  • Änderungen automatisch auf mein GitHub überträgt
  • die .bin und .dfu - Dateien automatisch auf meinen USB-Stick überträgt
  • die neuen Dateien / Ordner automatisch auf meinen Server überträgt sowie die Downloadseite bezüglich der Versionen updatet

  • Bedeutet: ein Befehl und vom Quelltext bis zu allen Binaries und nötigen Aktionen bezüglich Veröffentlichung läuft alles automatisch - auf der Kommandozeile gesteuert...

    Wenn ihr Interesse an dem Script habt bereinige ich es um die Dinge die nicht öffentlich sind (GitHub hochladen, hochladen auf meinen amateurfunk-sulingen.de Server) und veröffentliche es hier.

    Damit kann man
    1) seine eigenen Builds automatisieren
    2) ein wenig Bash lernen

    vy 73
    Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DL6KL on 31. July 2019, 06:37:41

Guten Morgen
Also ich hatte mich auch mal drangegeben.
Archlinux in der VM läuft und das make geht auch.
Der Gitpod auf der Seite von Github funktioniert auch.
Danke an Danilo
@Andreas An dem Script hätte ich auch Interesse.

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 31. July 2019, 07:03:04

Ich werde bei Gelegenheit die Variablen besser benennen und die Kommentare auf Englisch abändern. Dann werde ich das Script hier hochladen und ggf. auch in das GitHub Repo mit reinlegen.

vy 73
Andreas

Title: Script für automatisiertes Serienbauen
Post by: DF8OE on 31. July 2019, 15:55:29

Hier wie versprochen mein Bash-Script. Die Möglichkeit eines Scriptings erlaubt es ohne Interaktionen Prozesse weitestgehend frei individuell zu automatisieren und trotzdem transparent zu lassen - ein für mich extrem wichtiger Punkt. Sehr viele Dinge gehen bei mir "automatisch" (und zwar nach einem Automaten dessen Arbeitsweise ich exakt kenne, da ich ihn selbst gebaut habe): einmal Arbeit und Gehirnschmalz investieren und dann bei der Anwendung zurücklehnen und lächeln...


Am Anfang des Scriptes sind einige Pfade die ihr an eure Gegebenheiten anpassen müsst. Die Ordner auf die die jeweilige Zeile zeigt müssen bereits existieren!

Have fun :D

Code:

#!/bin/bash

# ...some paths & configuration
#OPT_GCC_ARM=/opt/gcc-arm-none-eabi-8-2018-q4-major/
OPT_GCC_ARM=/opt/gcc-arm-none-eabi-8-2019-q3-update

LOCALUPLOADPATH=/home/andreas/abc/upload
COMPILEPATH=/home/andreas/git/uhsdr/mchf-eclipse
BINARYPATH=/home/andreas/abc/binaries
USBNAME=/media/andreas/FIRMWARE
RESULTFILE=$LOCALUPLOADPATH/result.txt

# how many cores does your CPU of your PC have?
#CPUCORE="" # 1 core
#CPUCORE="-j2" # 2 core
CPUCORE="-j4" # 4 core
#CPUCORE="-j8" # 8 core
#CPUCORE="-j16" # 16 core

# nothing user-editable below this line!

export OPT_GCC_ARM
BUILDSMALL=0

# clear action log
echo "Errorlog:" > $RESULTFILE

# retrives firmware version
MAJOR=`cat $COMPILEPATH/src/uhsdr_version.h | grep MAJOR | egrep -v UHSDR_VERSION | cut -d '"' -f 2`
MINOR=`cat $COMPILEPATH/src/uhsdr_version.h | grep MINOR | egrep -v UHSDR_VERSION | cut -d '"' -f 2`
RELEASE=`cat $COMPILEPATH/src/uhsdr_version.h | grep RELEASE | egrep -v UHSDR_VERSION | cut -d '"' -f 2`
FVERSION=$MAJOR.$MINOR.$RELEASE

# retrieves bootloader version
BVERSION=`cat $COMPILEPATH/src/uhsdr_version.h | grep -m 1 'UHSDR_BOOT_VERS' | cut -d '"' -f 2`

# is USB key mounted?
mount | grep $USBNAME > /dev/null
if [ "$?" == 0 ];then
ISMOUNTED=1
else
ISMOUNTED=0
fi

# build_process call: build_process (1)BUILDNAME (2)TRX_ID (3)TRX_NAME (4)BUILDFOR (5)VERSION (6)TRX_BUILD (7)CONFIGFLAGS (8)ADD_PATH (9)RECENTPATH
function build_process
{
BUILDNAME=$1
export TRX_ID=$2
export TRX_NAME=$3
export BUILDFOR=$4
VERSION=$5
TRX_BUILD=$6
CONFIGFLAGS=$7
ADD_PATH=$8
RECENTPATH=$9

# is binary already built for this target / version combination?
if [ "$(tail -n 1 $LOCALUPLOADPATH/$TRX_BUILD-$BUILDNAME-history.txt 2>/dev/null)" == *"$VERSION"* ] && [ "$CHOICE" == *"server"* ];then
   echo "$VERSION build already exists for $BUILDNAME $TRX_BUILD $BUILDFOR!" >> $RESULTFILE
else
   if [ "$BUILDNAME" == "firmware" ];then
    PREFIX="fw"
   else
    PREFIX="bl"
   fi

   # creating folders, suppress "already exist..." messages
   mkdir $LOCALUPLOADPATH/$BUILDNAME/ 2>/dev/null
   mkdir $LOCALUPLOADPATH/$BUILDNAME/$VERSION 2>/dev/null
   mkdir $LOCALUPLOADPATH/$BUILDNAME/$VERSION/$TRX_NAME 2>/dev/null
   mkdir $LOCALUPLOADPATH/$BUILDNAME/$VERSION/$TRX_NAME/$ADD_PATH 2>/dev/null

   cd $COMPILEPATH

   echo -e "building $BUILDNAME for $TRX_BUILD...\n"
   if [ "$BUILDNAME" == "firmware" ];then
    if ! [ "$BUILDFOR" == "F4-512KB" && "$BUILDSMALL" == "0" ];then
      make $CPUCORE CONFIGFLAGS="$CONFIGFLAGS" all
    fi
    if [ "$BUILDFOR" == "F4" ];then
      BINLENGTH=$(ls -l fw-mchf.bin | cut -d ' ' -f 5)
      if [ "$BINLENGTH" -gt 458752 ];then
       BUILDSMALL=1
      fi
    fi
   else
    make $CPUCORE CONFIGFLAGS="$CONFIGFLAGS $SPB" bootloader
   fi
   if [ "$?" == 1 ];then
    echo "$TRX_NAME-$BUILDFOR build errored - skipping." >> $RESULTFILE
   else
    if [ "$BUILDFOR" == "F4-512KB" ] && [ "$BUILDSMALL" == "0" ];then
      touch $LOCALUPLOADPATH/$BUILDNAME/$VERSION/$TRX_NAME/$ADD_PATH/"no small build needed - standard build fits into 512KB!"
    else
      cp $PREFIX-$TRX_ID.bin $LOCALUPLOADPATH/$BUILDNAME/$VERSION/$TRX_NAME/$ADD_PATH
      chmod 644 $LOCALUPLOADPATH/$BUILDNAME/$VERSION/$TRX_NAME/$ADD_PATH/$PREFIX-$TRX_ID.bin
      cp $PREFIX-$TRX_ID.dfu $LOCALUPLOADPATH/$BUILDNAME/$VERSION/$TRX_NAME/$ADD_PATH
      if [ "$ISMOUNTED" == 1 && "$BUILDFOR" != "F4-512KB" ];then
       cp $PREFIX-$TRX_ID.bin $USBNAME
       echo "auf USB-Stick kopiert!"
      fi

      cp $PREFIX-$TRX_ID.bin $BINARYPATH/$RECENTPATH
      chmod 644 $BINARYPATH/$RECENTPATH/$PREFIX-$TRX_ID.bin
      cp $PREFIX-$TRX_ID.dfu $BINARYPATH/$RECENTPATH
      make clean >/dev/null
      cd $LOCALUPLOADPATH/$BUILDNAME/$VERSION/$TRX_NAME/$ADD_PATH

      # install locally produced mdsums for checking correct transfers to server
      md5sum -b * > md5sums.txt
    fi
   fi
   echo -e "\n\n"
fi
}


# start of main program
CHOICE=$(dialog --backtitle "Automatic UHSDR Firmware builds and Transfers" \
--checklist "What shall I do for you, master?" 0 0 12 \
"firmware mcHF standard " "" on \
"firmware mcHF 512KB " "" on \
"firmware OVI40 F7 " "" on \
"firmware OVI40 H7 " "" on \
"bootloader mcHF " "" off \
"bootloader OVI40 F7 " "" off \
"bootloader OVI40 H7 " "" off 3>&1 1>&2 2>&3 3>&-)

clear

if [ "$?" = "1" ];then
echo "nothing to do - finished."
exit 0
fi


# building scenarios
if [ "$CHOICE" == *"firmware mcHF standard"* ];then
build_process firmware mchf mcHF F4 $FVERSION mcHF "-DUI_BRD_MCHF -DRF_BRD_MCHF"
fi
if [ "$CHOICE" == *"firmware mcHF 512KB"* ];then
build_process firmware mchf mcHF F4-512KB $FVERSION mcHF-512KB "-DUI_BRD_MCHF -DRF_BRD_MCHF" MCU_512KB MCU_512KB
fi
if [ "$CHOICE" == *"firmware OVI40 F7"* ];then
build_process firmware 40sdr OVI40 F7 $FVERSION OVI40-F7 "-DUI_BRD_OVI40 -DRF_BRD_MCHF -DRF_BRD_OVI40" F7
fi
if [ "$CHOICE" == *"firmware OVI40 H7"* ];then
build_process firmware ovi40 OVI40 H7 $FVERSION OVI40-H7 "-DUI_BRD_OVI40 -DRF_BRD_MCHF -DRF_BRD_OVI40" H7
fi
if [ "$CHOICE" == *"bootloader mcHF"* ];then
build_process bootloader mchf mcHF F4 $BVERSION mcHF "-DUI_BRD_MCHF"
fi
if [ "$CHOICE" == *"bootloader OVI40 F7"* ];then
build_process bootloader 40sdr OVI40 F7 $BVERSION OVI40-F7 "-DUI_BRD_OVI40" F7
fi
if [ "$CHOICE" == *"bootloader OVI40 H7"* ];then
build_process bootloader ovi40 OVI40 H7 $BVERSION OVI40-H7 "-DUI_BRD_OVI40" H7
fi


echo -e "\n\n\n"
sed -i '/Script/d' $RESULTFILE

# show history of building / uploading which is not on standard output
cat $RESULTFILE 2>/dev/null
rm $RESULTFILE 2>/dev/null


Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 31. July 2019, 16:45:15

Immer her damit...

Ich habe mit Absicht keine haarklein genaue Beschreibung gemacht, damit der "Lerneffekt" eine Chance bekommt...

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 03. August 2019, 08:53:00

Ich bin bei meinen (Software)-Arbeiten öfter in der Verlegenheit, irgendwas "Quelloffenes" von GitHub zu brauchen. Und öfter finde ich auch darin kleine Fehler, die ich gerne (für alle) mit beseitigen helfen würde. Das ist Open-Source: nehmen und geben... Bislang habe ich das Repo also immer auf mein Github geforked, dann lokal heruntergezogen, dann damit gearbeitet. Manchmal für einen einzigen Pull Request...

Ich habe nun diesen Beitrag (https://stackoverflow.com/questions/14906187/how-to-submit-a-pull-request-from-a-cloned-repo) gefunden und bin auf "hub" gestoßen. Ein geniales Tool für die Kommandozeile - eine wirklich sinnvolle Erweiterung von "git".

Das Tool "hub" (https://hub.github.com)

Wieder etwas was man nur auf der Kommandozeile so effektiv und schnell lösen kann. Unter Linux geht das direkt - wer Windows hat braucht eine VM und eine vollständige Linux-Installation darauf oder das WSL.

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 03. August 2019, 09:28:27

Version von Hub die für mein "Siduction" (Debian experimental based) in den Repos ist: 2.7.0
Was für "Debian stable" oder "Ubuntu" in den Repos ist weiß ich nicht, weil ich beides nicht mehr habe (Debian stable nicht weil mir die Software aus den Repos zu alt ist und Ubuntu nicht weil der "Schnüffel-Einfluss" von Microsoft immer größer wird).

Version von Hub die für mein "Arch" in den Repos ist: 2.12.3

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 03. August 2019, 12:45:24

Hallo Thomas,

Scripte die ich nur für mich als User "andreas" brauche liegen grundsätzlich unter
/home/andreas/bin
das kann man auch schreiben als:
~/bin

Die Schlange ist immer das Homeverzeichnis des Users als der Du gerade arbeitest.

Da kopierst Du das Script rein. Wie es heißt ist egal. Gib ihm aber die Rechte ausführbar zu sein mit:
chmod 777 ~/bin/name-deines-scriptes

Nun passt Du noch die Pfade im Script an (muss nur einmal gemacht werden - oder, wenn Du einen andere Toolchain bekommst / nehmen willst auch dann. Wenn Du Arch Linux benutzt, kannst Du den OPT_GCC..... auch einfach auskommentieren (eine # an den Anfang der Zeile stellen) - denn unter Arch ist die neueste Toolchain schon aus den Repos installiert und braucht nicht zusätzlich gepflegt werden.

OPT_GCC_ARM=/opt/gcc-arm-none-eabi-8-2019-q3-update
LOCALUPLOADPATH=/home/andreas/abc/upload
COMPILEPATH=/home/andreas/git/uhsdr/mchf-eclipse
BINARYPATH=/home/andreas/abc/binaries
USBNAME=/media/andreas/FIRMWARE
RESULTFILE=$LOCALUPLOADPATH/result.txt

Bei Letzterem musst Du nur den eigentlichen Namen (result.txt) anpassen - wenn Du mit dem nicht leben kannst. Der Rest der Zeile passt schon.

Die Anzahl deiner CPU-Kerne gibst Du an damit Du auf allen Kernen gleichzeitig bauen kannst (das beschleunigt den Vorgand sehr):
CPUCORE="-j4" # 4 core


Ich denke, die Pfade sind aufgrund der Namen eindeutig zuzuordnen. Wenn nicht: fragen.

Eine Frage hast Du ja schon gestellt:
Ich möchte, dass mir gleich alle Binaries auf einen eingesteckten und gemounteten (!!) USB-Stick kopiert werden, damit ich nach erfolgreichem Bau nur den Stick unmounten muss und sofort auf allen Geräten damit ein Update machen kann.

Du musst also einen USB-Stick anstecken und mounten. Wo der dann gemounted ist unterscheidet sich je nach Linux-Distri (auch an diesen schönen kleinen Unterschieden beißen sich viele Viren die Zähne aus weil eben KEIN uniformes System vorliegt).

Bei Debian-basierten Distris ist der Pfad gewöhnlich
/media/dein-username/name-des-sticks

bei Arch-basierten ist es
/run/media/dein-username/name-des-sticks

Aufrufen tust Du das Script mit
~/bin/name-des-scriptes

Viel Erfolg!

EDIT:
Der Befehl um unter Linux den Inhalt von Verzeichnissen aufzulisten lautet
ls
nicht dir !

"dir" ist nur aus Kompatibilitätsgründen zu good-old-DOS symbolisch verlinkt. Gewöhn Dir bitte "ls" an.

EDITEDIT:
Wenn Du mit nano, vi, vim und Co. noch nicht klar kommst, nimm entweder einen grafischen Editor oder benutze den "mc". Der ist vielen aus DOS-Zeiten noch als "Norton Commander" (nc) bekannt. Selbst ich benutze den noch oft. Ist sowas wie ein "Schweizer Taschenmesser" ::)

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 03. August 2019, 17:16:35

Wenn da was mit "grep" kommt ist da was fundamental falsch.

Installiere bitte mc:

yay -S mc

...und schau Dir mal den Inhalt der Datei an wo mein Script drin sein soll. Pack es aus dem UHSDR Ordner raus (System und Ordnung angewöhnen) in ein von Dir erstelltes bin - Verzeichnis in deinem Heimatordner.

Und dann gehen wir step-by-step vor.

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DJ3FV on 04. August 2019, 06:47:07

Hallo Thomas,

versuch doch bitte mal das Script anders afzurufen, z.B.

Code:
bash ~/bin/mein_script.sh

oder du gehst direkt ins das Verzeichnis und rufst das Script dort auf

Code:
cd ~/bin
./mein_script.sh

Ich würde versuchen ein ausführbares Script nicht mit der Extension .txt enden zu lassen sonder ganz ohne Extension oder mit '.sh' schon alleine um später Scripte und echte Text Dateien unterscheiden zu können und auch weil einige Extensionen mit einer Anwendungen verknüpft sind oder sein könnten. Bei txt wäre das zum Beispiel ein Textbearbeitungsprogramm oder ein einfacher Texteditor.

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 04. August 2019, 06:54:53

Ich denke Du hast auf deinem Arch eine andere Shell als die Bash installiert. Es gibt unter Linux nicht nur eine Shell (genauso wie es nicht nur eine grafische Oberfläche gibt).

Installiere bitte mal die bash und versuche es dann nochmal:

yay -S bash

Du kannst unter Linux mehrere verschiedene Shells gleichzeitig installiert haben (genauso wie Du mehrere grafische Oberflächen gleichzeitig installiert haben kannst). Bei den Shells z.B. wird durch die erste Zeile des Scriptes bestimmt, mit welcher Shell sie ausgeführt werden (in meinem Fall #!/bin/bash ). Auch das ist wieder ein Sicherheitsmerkmal. Die Dialekte der Shells sind zwar sehr ähnlich - aber nicht identisch. Nicht jedes Script wird auf jedem System laufen - einfach weil die nötige Shell nicht installiert ist...

Ein ausführbares Script mit .txt zu benennen ist sehr unglücklich. Wenn Du es auf der Kommandozeile aufrufst, wird das passieren, was Du willst (es wird ausgeführt). Aber wenn Du es in einer grafischen Oberfläche anklickst passiert etwas anderes - und bei der Endung .txt vermutlich nicht das, was Du möchtest.

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DL2GMI - Michael (H44MI) on 04. August 2019, 07:29:54

Ich bennene bash-Scripte immer mit sh - dann kann ich das klarer zuordnen.

Den Ordner bin gibt es auf jedem Linux schon von werk - da liegen quasi die Programme drin, die direkt über "/programmname" gestartet werden können.

Dein Script kann auch in /home/user/sonstwie liegen und darin ausgeführt werden.

wenn Dein Script also mcHF.sh heisst und in /home/dl8ebd/ liegt, kannst du es aufrufen mit ./home/dl8ebd/mcHF.sh

EDIT DF8OE: Habe meinen Fehler korrigiert und alle anderen Einträge die aus meinem Fehler resultierten gelöscht/angepasst - Sorry für die Verwirrung!

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 04. August 2019, 07:52:22

Hallo Thomas,

Es gibt "ab Werk" die Ordner /bin und /usr/bin. Der Slash am Anfang bedeutet: das Dateisystem wird von ganz unten, also von root ab (/), gesehen.

Diese Ordner fasst Du bitte nicht an: sie sind für das Paketsystem der Distri "reserviert". Wieder ein Sicherheitsaspekt: Es gibt eine festgelegte Ordnung wo was hinzukommen hat - deswegen ist ein Linux-System viel aufgeräumter als ein Windows-System. Installiere bei beiden mal eine großes Pakt (wie z.B. Libre-Office",und deinstalliere es sofort wieder ohne es zu benutzen. Das Linux-System wird genauso groß sein wie vor der Installation - beim Windows-System befürchte ich es ist jetzt größer ::)

Dann gibt es noch die Ordner in /usr/local/ - dort liegt auch ein bin. Da könntest Du die Scripte reintun die Du selbst erstellt hast. Ich mache das nur, wenn sie systemweit (für alle User die sich anmelden könen) erreichbar sein sollen. Für meine "privaten" Scripte habe ich in meinem Home-Ordner ein eigenes bin angelegt - und Scripte die dort sind muss man in der Tat mit vollem Pfad starten.

EDIT:
Und dann gibt es noch die Ordner sbin. Die kann nur root öffnen, die Programme / Scripte darin sehen und / oder starten.

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 04. August 2019, 10:24:21

"Eigentlich" braucht man bei Linux nicht "stochern", wenn irgendwas nicht läuft. Fehlermeldungen sind eindeutig und interpretierbar, es werden (hier nicht - aber bei anderen Problemen) Logs geschrieben...

Mich machte deine Aussage stutzig:
bash: mcHF.txt: Kommando nicht gefunden.

Da die Bash wegen des Shebangs im Script aufgerufen wird kann das nur bedeuten dass das Kommando "bash" nicht gefunden wurde. Vielleicht hast Du mit der "sh" oder der "zsh" gearbeitet. Da ich schon lange kein Arch mehr frisch aufgesetzt habe (immer nur mit meinen Installationsscripten die ein Komplettsystem aufsetzen) weiß ich nicht ad Hoc welche Shell da default drin ist.

EDIT:
Den Geschwindigkeitsvorteil kann man natürlich nur dann auschöpfen wenn Linux als Alleinsystem läuft - nicht in einer VM.

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 04. August 2019, 11:05:49

Hallo Thomas,

Wenn Du einen Befehl der NICHT in den "Standard Ordnern" ist aufrufen willst musst Du den Pfad KOMPLETT angeben.

Also entweder

./home/thomas/bin/mcHF.sh (Sorry Michael für die Verwirrung!!)

ODER

bash /home/thomas/bin/mcHF.sh

Übrigens kannst Du auch die "automatische Eingabezeilenergänzung" für Dich arbeiten lassen. Die funktioniert mit der TAB Taste.

Gib mal auf der Kommandozeile ein

/ho

...und dann drück die TAB-Taste 8)

Wenn Du also deinen Befehl aktivieren willst der z.B. in /home/thomas/bin/mcHF.sh liegt dann brauchst Du nur

bash /ho
TAB
tho
TAB
bi
TAB
mc
TAB

zu drücken und dann wird jeweils der Rest automatisch ergänzt. Geht rattenschnell und vermeidet Schreibfehler (groß/klein, einfache Typos etc.)

Ist die Ergänzung nicht eindeutig möglich (z.B. weil es einen User thomas und einen User thomasio gibt) dann passiert beim ersten TAB NICHTS und beim zweiten TAB bekommst Du eine mögliche Auswahl für die Ergänzung angezeigt. Dann gibst Du einfach den nächsten Buchstaben ein der die möglichen Auswahlen unterscheidet und drpückst wieder TAB.

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 05. August 2019, 05:08:28

Ich habe wie schon geschrieben leider kein Arch mehr hier, das frisch installiert ist. Daher weiß ich nicht genau was in der Standardinstallation mit drin war...

Es könnte sein dass Dir das Paket "dialog" fehlt. Dies ist nötig um auf der Kommandozeile sowas wie eine "kleine grafische Oberfläche" darzustellen. Eine, die man komplett mit der Tastatur bedienen kann (TAB wechselt Felder, Pfeil auf und Pfeil ab gehen in Auswahldialogen rauf und runter, die Leertaste selektiert / deselektiert, ENTER bestätigt).

Also schau mal mit

yay -Qs dialog

nach ob das installiert ist. Und wenn nicht: Installiere es mit

yay -S dialog

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DJ3FV on 05. August 2019, 06:29:00

Typische Verdächtige in Linux wären u.a.
- sind alle Verzeichnisse vorhanden und so wie sie im Scrip verlangt werden?
- Sind sie korrekt geschrieben? z.B. steht uhsdr in script mit Lower Case.
In einem früheren Bericht habe ich es mit Upper Case also UHSDR gesehen. Linux ist key sensitive und für archlinux wären das z.B. zwei unterschiedliche Zeichenfolgen bzw. Namen.
Wenn man in einem Verzeichnis ist, kann man durch Eingabe von pwd nachschauen wo man ist und ggfs. den Pfad kopieren und im Script ablegen oder zumindest vergleichen. Damit wäre eine potentielle Fehlerquelle beseitigt oder ausgeschlossen.

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DJ3FV on 05. August 2019, 13:19:28

Liegt das Toolchain im richtigen Pfad und hat ausreichen Berechtigungen zur Ausführung durch einen nicht Root User?

/opt/gcc-arm-none-eabi-8-2019-q3-update


Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 05. August 2019, 14:13:38

Soweit kommt das Script ja noch gar nicht. Bevor irgendwas abläuft wird eine Dialogbox gezeigt bei der man entscheiden kann, was ablaufen soll ::) Und die ist schon nicht da. Daher mein Verdacht auf "dialog".

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 05. August 2019, 18:17:07

Sehr schön!

Und in der Tat: da lasse ich Dich alleine bis Du um Hilfe schreist. Das bekommst Du selbst raus - glaube ich zumindest!!!

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DL2GMI - Michael (H44MI) on 06. August 2019, 14:43:31

Lese dir die Fehlermeldung genau durch - das ist ein großer Vorteil von Linux: Es schreibt exakt hin, was das Problem ist.

Die meldungen weiter unten mit den 2 // sagen mir, das irgendwo ein Fehler drin ist. Daran kann man sich aber machen, wenn man den ersten Fehler weg hat.

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 06. August 2019, 16:23:15

Du hast doch die Toolchain aus den Repos installiert und benutzt keine externe: nur zu einer externen müsstest Du mit der Environment-Variable OPT_GCC_ARM=.... einen Pfad angeben.

Wenn Du keine externe (zusätzliche) Toolchain installiert hast und die aus den Repos nutzen willst ==> kommentiere den oben genannten Pfad mit einem # am Anfang der Zeile im Script aus.


EDIT:
Letzten Endes ist es so, dass das Script nicht - was es als "ordentliches Script" tun sollte - vorher alle Abhängigkeiten prüft und eine auch für Laien lesbare Fehlermeldung ausgibt. Wenn ich das nicht für eine allgemeine Veröffentlichung erstelle, lasse ich sowas gerne weg. Kostet nur Zeit und Mühe - und ich weiß es ja. Auch könnten die Pfade überprüft werden - geht alles. In meinem Script wird stumpf davon ausgegangen, dass alles, was reinkommt, auch stimmt und alle Abhängigkeiten (dialog...) gelöst sind. Und wenn nicht können auch mal ganz eigentümliche Fehler entstehen, z.B. "ganzzahliger Ausdruck erwartet". Das kommt, weil irgendwas vorher fehlgeschlagen ist, was in einer korrekten Umgebung nicht fehlschlagen kann.

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 06. August 2019, 17:05:13

...Du kannst jetzt auch MEHRERE Haken setzen und dann bauen. Also meinetwegen auch alles anhaken. Das ist ja der Vorteil des Scriptes. Es ist kein "Radiobutton"!

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 06. August 2019, 17:21:16

Genau! Da diese Scripte alle "reiner ASCII-Text" sind kann man das kinderleicht an seine Bedürfnisse anpassen.

In meinem Script sind noch folgende zusätzliche Dinge drin, die aber bei euch nicht funktionieren können und die ich daher vor Veröffentlichung weggelassen habe:

  • ganz am Anfang werde ich noch gefragt, ob die Version hochzählen soll und wenn ja, wie (Major/Minor/Build)
  • nach dem Bauen wird die neue Versionsnummer in meinem git-Verzeichnis committed (mit der Bemerkung dass eine neue Release gebaut wurde)
  • dann werden die Änderungen auf mein GitHub übertragen (dort authentifiziere ich mich nicht mit Passwort, sondern mit einem Zertifikat - dann bin ich immer "automatisch drin", wenn ich am richtigen Gerät arbeite (an dem wo auch das Zertifikat drauf ist)
  • danach werden die gebauten Strukturen (Firmware / Bootloader-Ordner) per scp auf meinen Server übertragen - ebenfalls per Zertifikat authentifiziert
  • danach werden auf meinem Server per ssh noch die md5sums überprüft

  • Den"aktuellen Build" erkennt das php-Script, das auf meinem Server läuft und die Box mit dem Firmware/Bootloader/latest/archive anzeigt, selbstständig anhand der Namen der Ordner (Versionsnummern).

    Es ist sozusagen alles automatisiert.

    vy 73
    Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 06. August 2019, 17:34:57

Ich weiß es nicht mehr genau. Ein paar Minuten sind es schon. Aber deutlich weniger als 5 Minuten.
Es ist ein Achtkernprozessor und ich habe 32GB RAM...

EDIT:
Und mein Linux läuft nicht in einer VM...

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 07. August 2019, 05:35:20

Ich lerne seit 2000. Damals habe ich mit der SuSE angefangen (ich weiß jetzt noch nicht mal mehr ob es die 5.x oder doch schon die 6.x war). Aber alles, was ich damals gelernt habe, kann man heute noch gebrauchen. Die Kenntnisse irgendwelcher \hhkey_local_machine\software\microsoft\office97\3524-23e5-68ab-126f dagegen ist lange obsolet. Ich liebe die Nachhaltigkeit - das sieht man auch schon an unserem Forum. Das Entwicklerteam hatte damals die Entwicklung / Unterstützung von YaBBSE eingestellt und in das neue SMF jede Menge zusätzlicher Funktionen eingebaut, die meiner Ansicht nach mit dem Sinn eines Forums nichts mehr zu tun hatten. Einige dieser neuen Features sind inzwischen auch nicht mehr verfügbar (weil es die Dienste in unserer schnellebigen Zeit nicht mehr gibt) oder sie verstoßen gegen Gesetze (DSGVO). Das ist das Gute an Open-Source: Niemand kann einen zwingen, diesen Wahnsinn mitzumachen. Also habe ich seitdem das Forenscript selbst weitergepflegt, Fehler beseitigt, Sicherheitsprobleme gefixt, Funktionen verbessert. Und es tut nach wie vor was es soll. Ich vergleiche auch gar nicht mehr Windows/Linux. Linux tut in allen Belangen was ich will, ich musste mich noch nie über eine (wirtschafts)politische Entscheidung ärgern oder mich gar fügen. Als erkennbar wurde, dass Ubuntu dank Canonical und seiner Zusammenarbeit mit Microsoft in eine Richtung driften würde die mir nicht gefallen würde: habe ich einfach mein Homeverzeichnis mit allen Einstellungen behalten und das System darunter von Ubuntu auf Debian umgestellt. Und nun lande ich mit allen Geräten nach und nach bei Arch - weil ich dort für mich noch mehr Vorteile sehe. Alles war MEINE Entscheidung - und zwar meine freie.

Noch ein paar Linux-Dinge:
Wenn Dich die genaue Zeit zum Bauen interessiert: kein Problem. Messe die Dauer mit dem Script selbst!
Ermittle die Startzeit mit

STARTTIME=$(date +%s)

nach dem Test ob der User OK oder ABBRUCH gewählt hat (das ist nach Zeile 135).
Dann miss am Ende nochmal die Zeit - und ermittle die Differenz in Minuten:Sekunden. Also ans Ende des Scriptes

ENDTIME=$(date +%s)
let TIME=$ENDTIME-$STARTTIME
ZEIT=$(date -d @$TIME +%M:%S)
echo "Der Bau dauerte "$ZEIT" Minuten."

Voilà ::)

Und wenn Du mal mit einem Befehl nicht klarkommst oder mehr über ihn wissen möchtest: Außer dem obligatorischen --help hinterher (das ja auch Windows-Befehle oft kennen) gibt es bei Linux für jeden Befehl ein "eingebautes Handbuch" - das "Manual".

gib einfach ein

man Befehl

...und Du siehst es. Mit den Pfeiltasten kann man blättern, mit q die Anzeige beenden. Man kann auch im Handbuch nach bestimmten Textstellen suchen - aber das ist ein neues Thema...

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DL6KL on 07. August 2019, 07:00:15

Guten Morgen Andreas.
Ich verfolge diesen Thread , ich habe archlinux in einer VM installiert und habe es bis zum Kompilieren der mcHF Software gebracht.
Meine Frage ist:
Der VM ist mir zu langsam und ich möchte das jetzt parallel zu WIN10 installieren.
Hatte es schon mal mit Siduction gemacht da ging das wie bei Ubuntu automatisch, musst nur in Grub die Reihenfolge ändern.
Wie ist das bei archlinux da da ja die Installation per Terminal erfolgt

Bin mittlerweile nicht mehr so fit in Linux da ich über längere Zeit nichts mehr dran getan hatte.Meine erste Version war die 0.99 von 1992 auf ca. 30 Disketten, lange ist es her.

73
Adolf

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 07. August 2019, 07:41:13

Hallo Adolf,

ein großes Manko ist bei Arch Linux dass es im Prinzip nur von Leuten installiert werden kann die schon ein gerütteltes Maß an Linux-Erfahrung haben. Mag das bei einer "Installation als alleiniges System" noch mit einem geringen Maß an Erfahrung gelingen - so steigen die Ansprüche bei Dingen wie "Parallelinstallationen" oder "EFI" drastisch an (und für "UEFI" gibt es bei den meisten Linux-Distributionen - außer bei der Microsoft-nahen Distribution "Ubuntu" - gar keine funktionierende Lösung). Bei Parallelinstallationen kenne ich mich leider nicht aus, weil ich mich damit weder beschäftigt habe noch es brauche.

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 07. August 2019, 09:02:33

Ich weiß auch nicht ob das immer noch so ist dass Windows bei fast jedem Update den mbr der Festplatte mit seinem eigenen Kram überschreibt, wodurch dann der Grub wieder weg ist und man nur Windows sieht. Das war zumindest in einer Zeit (ca. 14 Jahre her) wo ich mich das letzte Mal mit Dual-Boot beschäftigt habe noch so. Damals habe ich dann aufgegeben.

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 07. August 2019, 10:12:24

Was Windows angeht endet mein Wissen mit Windows XP. Das hatte ich zumindest in Ansätzen noch mitverfolgt. Das letzte Windows mit dem ich gearbeitet hatte war Windows 2000. Ich hatte dann vor ein paar Jahren noch ein Sondenjäger-Tool in C# geschrieben (auf Windows XP - so ca. 2014) und seitdem habe ich NULL Kontakt mehr mit Windows ::)

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DL6KL on 07. August 2019, 14:16:49

@Thomas
@Andreas
Vielen Dank Für eure Infos
Dann werdeich das auf einem extra PC machen.
73
Adolf

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 07. August 2019, 15:49:22

Wieviele Ziele? eins? oder alle vier (wobei ja nur drei gebaut werden müssen weil der normale mcHF Build ja in den "kleinen" passt)?

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 07. August 2019, 15:52:00

Uffffffff........

Bei mir dauern alle vier (also korrekt drei) 4:05 Minuten...

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 07. August 2019, 15:58:19

Auf jeden Fall: sehr deutlich... Ich schätze Du brauchst dann für alle drei Builds weniger als jetzt für einen.

vy 73
Andreas

Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: Co on 26. August 2019, 15:50:58

Hello Thomas,

If you want to take a preview of what you bought (in english, take a look at :

www.nylxs.com/docs/linuxpocketguide_3rdedition.pdf

It can also be downloaded but hardcopy is more practical.

regards

Co


Title: Re:Linux als Entwicklungsplattform für UHSDR
Post by: DF8OE on 26. August 2019, 18:00:25

Two important adavantage:
1) it is working "standalone" without power supply
2) It cannot hang or throw bluescreens ::)

vy 73
Andreas


Diskussions- und Newsboard des DARC-Ortsverbandes I40 | Powered by YaBB SE
© 2001-2003, YaBB SE Dev Team. All Rights Reserved.