Forum: Compiler & IDEs Go-Compiler für MSP430


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


Bewertung
1 lesenswert
nicht lesenswert
Hallo,

ich versuche einen sehr eingeschränkten Go-Compiler für den MSP430 zu 
bauen.
Es funktioniert noch fast gar nichts außer Variablenzuweisungen und 
Schleifen.
Damit lassen sich aber schon mal LEDs zum Leuchten bringen:
package main

import msp430 "msp430.io/g2553"

func main() {
  // Wachhund abstellen
  msp430.WDTCTL = msp430.WDTPW | msp430.WDTHOLD
  
  // LED an P1.0
  msp430.P1DIR |= 0x01
  msp430.P1OUT |= 0x01
}

Wer damit etwas spielen (mehr ist z.Z. nicht drin) will,
kann sich hier die passende Version runterladen:

Linux: https://ugo-compiler.de/bin/linux/amd64/ugo
macOS: https://ugo-compiler.de/bin/darwin/amd64/ugo
OpenBSD: https://ugo-compiler.de/bin/openbsd/amd64/ugo
Windows: https://ugo-compiler.de/bin/windows/amd64/ugo

von Paul penetrant panisch (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Jakob schrieb:
> Wer damit etwas spielen (mehr ist z.Z. nicht drin) will,
> kann sich hier die passende Version runterladen:
>
> Linux: https://ugo-compiler.de/bin/linux/amd64/ugo
> macOS: https://ugo-compiler.de/bin/darwin/amd64/ugo
> OpenBSD: https://ugo-compiler.de/bin/openbsd/amd64/ugo
> Windows: https://ugo-compiler.de/bin/windows/amd64/ugo

Uih, 8.7 Downloadpaket, scheint sehr gut dokumentiert zu sein ….

Scherz beiseite, warum soll ich bei so einem unnützen Kram nicht 
befürchten, einen Trojaner einzufangen!

von Blume (Gast)


Bewertung
5 lesenswert
nicht lesenswert
Was man auch vermisst ist eher ein Link auf ein Git Repro samt Anleitung 
wie man den Compiler selber bauen kann.

von Tom T. (tomth)


Bewertung
0 lesenswert
nicht lesenswert
Ist Go nicht sehr, sehr speicherintensiv? Eine x86 Hello World hat ja 
schlappe 900 KB.

von Jakob (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@Tom,

die vom offiziellen Go-Compiler erzeugten Binärdateien sind so groß, 
weil sie die Laufzeitbibliothek (und ggf. Debuginformationen ) 
enthalten:
https://golang.org/doc/faq#Why_is_my_trivial_program_such_a_large_binary

Der abgespeckte Compiler hingegen liefert keine Laufzeitbibliothek mit. 
Das hat den Vorteil, dass die Binärdateien deutlich kleiner sind, aber 
auch den Nachteil, dass Konstrukte, die eine Laufzeitbibliothek 
erfordern würden, nicht erlaubt sind (z.B. new, append usw.).

Zum Vergleich: Die Binärdatei des auf der Webseite angegebenen 
LED-Beispiels ist 72B groß (mit Alpha-Version ohne jegliche 
Optimierungen).

Wer mit dem MSP noch nichts gemacht hat, kann sich hier eine 
Minimalanleitung angucken:
http://ugo-compiler.de/fuer-anfaenger.html

von Alan (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Es wirklich ein hervorragendes Marketing, wenn man sieht, was der 
Weltschnüffeler No. 1 den Leuten so alles untergejubelt.

von Εrnst B. (ernst)


Bewertung
0 lesenswert
nicht lesenswert
Mal ganz blöd gefragt:

Für den GCC gibt es ein Go-Frontend und ein MSP430 Backend.

Lassen die sich nicht miteinander verheiraten, so dass nur noch 
Bibliotheken fehlen?

von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
Εrnst B. schrieb:
> Für den GCC gibt es ein Go-Frontend und ein MSP430 Backend.
>
> Lassen die sich nicht miteinander verheiraten, so dass nur noch
> Bibliotheken fehlen?

Meines Wissens nach ist der GCC nicht so modular aufgebaut, dass das 
ginge. Bei Clang/LLVM wäre das vielleicht der Fall, da man dort LLVM als 
"High-Level Assembler" hat, d.h. jeder Compiler der LLVM als Unterbau 
benutzt erzeugt eine "Intermediate Representation" (LLVM-IR). Für C/C++ 
macht das Clang und für Rust eben rustc. Darüber hinaus gibt es noch 
unzählige andere Frontends, wie D, Julia, etc. Alle erzeugen LLVM-IR, 
auf welche dann noch plattformspezifische Optimierungen angewandt werden 
und am Ende das fertige Binary herausfällt.

Das größere Problem an der Ausführung von "High-Level"-Sprachen wie Go 
auf Mikrocontrollern ist aber die Runtime, die eben nicht einfach so vom 
Himmel fällt und durchaus relativ groß ist und darüber hinaus noch der 
fehlende OS-Unterbau, auf welchen sich manche Funktionen der 
Standard-Library stützen.

Es gibt bereits eine Go-Implementierung die auf Mikrocontroller abziehlt 
und die ebenfalls LLVM als Backend nutzt. Bisher werden nur ARM und AVR 
explizit unterstützt aber da es ja für MSP430 ein LLVM-Backend gibt, 
könntest du das theoretisch zusammenfrickeln ;)
Hier der Link: https://tinygo.org/

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.