ct-Bot Firmware

Die Programmierung des c't-Bot
tobi

Re: ct-Bot Firmware

Beitrag von tobi » 10 Mär 2019, 18:51

cool danke. ich habs grad erstmal unter eclipse ausprobiert, da ist der fehler jetzt weg :)

mit make auf der konsole muss ich noch mal testen, nachdem ich mingw gestern noch mal neu installiert hatte wird jetzt make nicht mehr gefunden. stimmt wohl was mit dem pfad nicht mehr.
das ist aber auch nicht so wichtig für mich, ich verwende das makefile sonst eigentlich gar nicht. das hatte ich nur wegen der fehler ausprobiert, ob es einen unterschied macht.

Tobi

Nightwalker-87
Site Admin
Site Admin
Beiträge: 167
Registriert: 16 Apr 2017, 23:40

Re: ct-Bot Firmware

Beitrag von Nightwalker-87 » 10 Mär 2019, 19:25

@tobi: Der Test mit make war jedoch sehr hilfreich für uns um den Fehler überhaupt zu erkennen.
Bei mir klappt der Eclipse-build, aber der make-build mit

Code: Alles auswählen

make DEVICE=WIN32
schlägt unter Win10 immer noch fehl. :?
nw-87

eax
Friends of Sonny
Friends of Sonny
Beiträge: 110
Registriert: 18 Jan 2006, 16:16
Wohnort: Karlsruhe

Re: ct-Bot Firmware

Beitrag von eax » 10 Mär 2019, 20:22

Nightwalker-87 hat geschrieben:
10 Mär 2019, 19:25
@tobi: Der Test mit make war jedoch sehr hilfreich für uns um den Fehler überhaupt zu erkennen.
Das waren zwei unabhängige Fehler. Der Fehler beim Bauen mit make lag daran, dass ein neueres MinGW zusätzlich eine Library zum Linken braucht. Das Problem mit der CPU-Auslastung lag daran, dass MinGW fgets() scheinbar anders implementiert als Posix.
Nightwalker-87 hat geschrieben:
10 Mär 2019, 19:25
Bei mir klappt der Eclipse-build, aber der make-build mit

Code: Alles auswählen

make DEVICE=WIN32
schlägt unter Win10 immer noch fehl. :?
Es muss auch

Code: Alles auswählen

make DEVICE=PC
heißen.
Timo -- Meine Beiträge sind unter CC-BY-SA freigegeben

Nightwalker-87
Site Admin
Site Admin
Beiträge: 167
Registriert: 16 Apr 2017, 23:40

Re: ct-Bot Firmware

Beitrag von Nightwalker-87 » 10 Mär 2019, 20:30

Das ändert nix am Ergebnis. Das Log spare ich mir mal, da der Output der gleiche ist wie schon gepostet.
nw-87

tobi

Re: ct-Bot Firmware

Beitrag von tobi » 10 Mär 2019, 22:24

habs grad noch mal auf der konsole mit make ausprobiert, funktioniert bei mir :)
ich habe make DEVICE=PC verwendet. vorher war bei mir PATH falsch gesetzt, deshalb ging es nicht.

Tobi

Nightwalker-87
Site Admin
Site Admin
Beiträge: 167
Registriert: 16 Apr 2017, 23:40

Re: ct-Bot Firmware

Beitrag von Nightwalker-87 » 10 Mär 2019, 22:52

Hm, nee das ist es hier nicht: Bei mir ist die Einstellung so wie in der Installationsanleitung:

Trac-Installationsanleitung

Der Fehler tritt beim Linken auf.
nw-87

Nightwalker-87
Site Admin
Site Admin
Beiträge: 167
Registriert: 16 Apr 2017, 23:40

Re: ct-Bot Firmware

Beitrag von Nightwalker-87 » 11 Mär 2019, 21:26

Also die folgenden Konsolen-Builds rennen bei mir unter Windows 10 mit der Atmel AVR-8 v3.6.1 Toolchain nun fehlerfrei durch:

Code: Alles auswählen

make DEVICE=MCU MCU=atmega1284p

Code: Alles auswählen

make DEVICE=MCU MCU=atmega644p

Code: Alles auswählen

make DEVICE=MCU MCU=atmega644
Nach dem erfolgreichen obigen Build-Test mit der Version 3.6.1 auf der Konsole und in Eclipse, habe ich bei dieser Gelegenheit die Toolchains in der Installationsanleitung entsprechend aktualisiert. Die Links zu den Atmel-AVR-Toolchains waren nach der Übernahme von Atmel durch Microchip übrigens ohnehin nicht mehr erreichbar.

Edit: Darüber hinaus habe ich die obigen Builds auch mit dieser AVR-GCC 8.3.0 for Windows 32 and 64 bit-Toolchain (zip-Archiv). Diese stammt von http://blog.zakkemble.net/avr-gcc-builds/ Hier hat sich anscheinend mal jemand die Mühe gemacht eine avr-gcc Toolchain auf eine aktuellere Code-Basis zu setzen. Vielleicht stößt das ja hier bei jemandem auf Interesse... :wink:

aber

Code: Alles auswählen

make DEVICE=PC
schlägt beim Linken fehl. Der Output ist nach wie vor identisch zum geposteten Paste.
@eax: Könntest du dir das nochmal ansehen? Es scheint als wäre da immer noch ein Problem vorhanden. :?
nw-87

VDX
Friends of Gort
Friends of Gort
Beiträge: 99
Registriert: 26 Jan 2006, 22:43
Wohnort: Großkrotzenburg (Main-Kinzig-Kreis)

Re: ct-Bot Firmware

Beitrag von VDX » 12 Mär 2019, 00:06

... ich habe aktuell vor Allem ArduinoDue im Einsatz und würde mich auch noch für Teensy3.6 interessieren, da kleiner und vorhanden :wink:

Viktor
Ciao, Viktor --- Aufruf zum Projekt "Müll-freie Meere" - https://reprap.org/forum/list.php?426

eax
Friends of Sonny
Friends of Sonny
Beiträge: 110
Registriert: 18 Jan 2006, 16:16
Wohnort: Karlsruhe

Re: ct-Bot Firmware

Beitrag von eax » 12 Mär 2019, 00:55

Nightwalker-87 hat geschrieben:
11 Mär 2019, 21:26
Also die folgenden Konsolen-Builds rennen bei mir unter Windows 10 mit der Atmel AVR-8 v3.6.1 Toolchain nun fehlerfrei durch:

Code: Alles auswählen

make DEVICE=MCU MCU=atmega1284p

Code: Alles auswählen

make DEVICE=MCU MCU=atmega644p

Code: Alles auswählen

make DEVICE=MCU MCU=atmega644
Nach dem erfolgreichen obigen Build-Test mit der Version 3.6.1 auf der Konsole und in Eclipse, habe ich bei dieser Gelegenheit die Toolchains in der Installationsanleitung entsprechend aktualisiert. Die Links zu den Atmel-AVR-Toolchains waren nach der Übernahme von Atmel durch Microchip übrigens ohnehin nicht mehr erreichbar.

Edit: Darüber hinaus habe ich die obigen Builds auch mit dieser AVR-GCC 8.3.0 for Windows 32 and 64 bit-Toolchain (zip-Archiv). Diese stammt von http://blog.zakkemble.net/avr-gcc-builds/ Hier hat sich anscheinend mal jemand die Mühe gemacht eine avr-gcc Toolchain auf eine aktuellere Code-Basis zu setzen. Vielleicht stößt das ja hier bei jemandem auf Interesse... :wink:
Hast du mal ausprobiert, ob der Bot-Code mit einer neueren Version der avr-Toolchain noch funktioniert?
Ich meine mal gelesen zu haben, dass bei neueren avr-gccs der Code für die Interrupt-Handler geändert/optimiert wurde. Da bin ich mir nicht mehr so sicher, ob das "OS" auf dem Bot damit noch korrekt funktioniert, weil das doch stark Hardware- und compilerabhängig gebaut ist. Deshalb hätte ich da Sorge, dass es dann relativ schnell crasht, wenn auf die SD-Karte oder so zugegriffen wird.

Also sollte man auf alle Fälle mal testen, bevor man die Anleitung aktualisiert.

Nightwalker-87 hat geschrieben:
11 Mär 2019, 21:26
aber

Code: Alles auswählen

make DEVICE=PC
schlägt beim Linken fehl. Der Output ist nach wie vor identisch zum geposteten Paste.
@eax: Könntest du dir das nochmal ansehen? Es scheint als wäre da immer noch ein Problem vorhanden. :?
Zum Verständnis: du bekommst mit

Code: Alles auswählen

make DEVICE=WIN32
und mit

Code: Alles auswählen

make DEVICE=PC
dasselbe Ergebnis? Das kann ja irgendwie nicht sein... mach mal ein

Code: Alles auswählen

git clean -dfx
zum Aufräumen.
Timo -- Meine Beiträge sind unter CC-BY-SA freigegeben

Nightwalker-87
Site Admin
Site Admin
Beiträge: 167
Registriert: 16 Apr 2017, 23:40

Re: ct-Bot Firmware

Beitrag von Nightwalker-87 » 12 Mär 2019, 12:36

eax hat geschrieben:
12 Mär 2019, 00:55
Zum Verständnis: du bekommst mit
make DEVICE=WIN32 und mit make DEVICE=PC dasselbe Ergebnis?
Das kann ja irgendwie nicht sein... mach mal ein git clean -dfx zum Aufräumen.
nach git clean -dfx (jeweils) ergibt
  • make DEVICE=WIN32 diesen Output (Paste-Availability 1 week) --> FAIL
  • make DEVICE=PC diesen Output (Paste-Availability 1 week) --> PASS; kommt nun also fehlerfrei durch - warum auch immer... :roll:

    sowie mit der Atmel AVR-8 Toolchain v3.6.1 (welche laut Beschreibung identisch mit der Version 5.4 aus dem Debian-Buster-Repo ist, die ich unter Linux schon eine Weile verwende)
  • make DEVICE=MCU MCU=atmega1284p,
  • make DEVICE=MCU MCU=atmega644p und
  • make DEVICE=MCU MCU=atmega644,
    aufeinanderfolgend diesen Output (Paste-Availability 1 week) --> ALL PASS
Daraus schlussfolgere ich, dass es rund um mingw noch immer ein Problem gibt.
nw-87

Nightwalker-87
Site Admin
Site Admin
Beiträge: 167
Registriert: 16 Apr 2017, 23:40

Re: ct-Bot Firmware

Beitrag von Nightwalker-87 » 12 Mär 2019, 13:54

eax hat geschrieben:
12 Mär 2019, 00:55
Hast du mal ausprobiert, ob der Bot-Code mit einer neueren Version der avr-Toolchain noch funktioniert?
Ich meine mal gelesen zu haben, dass bei neueren avr-gccs der Code für die Interrupt-Handler geändert/optimiert wurde. Da bin ich mir nicht mehr so sicher, ob das "OS" auf dem Bot damit noch korrekt funktioniert, weil das doch stark Hardware- und compilerabhängig gebaut ist. Deshalb hätte ich da Sorge, dass es dann relativ schnell crasht, wenn auf die SD-Karte oder so zugegriffen wird.

Also sollte man auf alle Fälle mal testen, bevor man die Anleitung aktualisiert.
In der Anleitung findet sich für Win und Linux kein Direktlink zum Download dieser spezifischen Version sondern nur ein Link auf die neue Download-Seite. Komplett mit Hardware testen kann ich hier lokal nicht alles, da ich kein Display und kein Erweiterungsboard mehr habe. Vielleicht kann tobi das mal aufspielen, wenn er seinen bot fertig entstaubt hat. :?:
nw-87

tobi

Re: ct-Bot Firmware

Beitrag von tobi » 16 Mär 2019, 15:16

ich kann da gern was testen, klar. das erweiterungsmodul habe ich aber auch nicht.

Tobi

Nightwalker-87
Site Admin
Site Admin
Beiträge: 167
Registriert: 16 Apr 2017, 23:40

Re: ct-Bot Firmware

Beitrag von Nightwalker-87 » 17 Mär 2019, 00:10

Cool, danke für das Angebot - das mit dem Erw-Board ist nicht so schlimm vorerst, das wird man schon auch noch getestet bekommen...
Nachdem es unter Win ja diese zunächst unbemerkte Inkompatibilität gab (z.T. noch gibt?) bin ich nun erstmal zur alten Codebasis zurückgekehrt und teste grade das Durchkompilieren nativ unter Windows und Linux. Erst wenn sich da alles geklärt hat bietet sich ein Test an - dauert also noch etwas.
Vielleicht lassen sich bei der Gelegenheit code-technisch auch noch ein paar andere Dinge bereinigen / optimieren, die aktuell über die Einstellungen ausgeblendet sind und daher nicht in Erscheinung treten.
nw-87

Nightwalker-87
Site Admin
Site Admin
Beiträge: 167
Registriert: 16 Apr 2017, 23:40

Re: ct-Bot Firmware

Beitrag von Nightwalker-87 » 18 Mär 2019, 01:02

Was mir aktuell noch nicht klar ist: Wie wird unter Windows bei make DEVICE=PC eigentlich unterschieden ob ich den Code für den RPi3 oder den für x86 (-DWIN32) bauen will? Daher kam auch diese Unklarheit rund um DEVICE= PC und DEVICE=WIN32. Für das RPi-Target gilt ja schließlich auch DEVICE=PC.

Bei mir läuft make DEVICE=PC immer noch fehlerfrei durch, scheint also tatsächlich ok zu sein. Sollte also nun für Windows passen.

@Tobi: Hättest du Lust den Develop-Tree hier zu testen Develop HEAD ? Die zusätzlichen Warnings sind hier wieder ausgeschaltet. Habe dafür nun einen extra Dev-Zweig angelegt, damit das bei Tests nicht weiter ins Auge springt.

Gerne auch mal auf dem Bot wenn dir danach ist. :lol:

nw-87
nw-87

eax
Friends of Sonny
Friends of Sonny
Beiträge: 110
Registriert: 18 Jan 2006, 16:16
Wohnort: Karlsruhe

Re: ct-Bot Firmware

Beitrag von eax » 19 Mär 2019, 00:27

Nightwalker-87 hat geschrieben:
18 Mär 2019, 01:02
Was mir aktuell noch nicht klar ist: Wie wird unter Windows bei make DEVICE=PC eigentlich unterschieden ob ich den Code für den RPi3 oder den für x86 (-DWIN32) bauen will? Daher kam auch diese Unklarheit rund um DEVICE= PC und DEVICE=WIN32. Für das RPi-Target gilt ja schließlich auch DEVICE=PC.
Also das Software-Framework besteht grob gesagt aus drei Schichten (*): ganz "oben" das Verhaltenssystem, darunter der plattformunabhängige Code und ganz "unten" der Treibercode. Letzterer hängt natürlich von der Plattform/Schnittstelle ab, auf der die Software laufen soll.
Von dieser Treiber-Schicht gibt es zwei Implementierungen, eine für MCU und eine für PC. MCU bedeutet dabei "für bare-metal für ATmega" und PC bedeutet "für die POSIX-Schnittstelle". Sowohl Linux, macOS als auch MinGW/msys implementieren POSIX. Soweit zur "Plattform", auf der die Software läuft. Im Makefile kann mit DEVICE die Plattform/Treiberschicht ausgewählt werden, die verwendet werden soll, also MCU oder PC.
Unabhängig davon gibt es noch eine Hardware-Architektur, für die der Code übersetzt wird. Das kann sowas sein wie x86_64, IA-32, ARMv7-A, ARMv8-A usw. Diese wird im Makefile über die Variable BUILD_TARGET ausgewählt. (**)


(*) Wobei das im Code nicht ganz so strikt getrennt ist, wie es in der Theorie klingt. Insbesondere, weil es auch noch den Unterschied realer Bot zu simulierter Bot gibt, der sich nicht 1:1 auf diese Schichten abbilden lässt.

(**) Streng genommen wählt BUILD_TARGET nicht die Hardware-Architektur aus, sondern den Compileraufruf. In unserem Fall heißen die Befehle zum Aufruf des gcc-Compilers jedoch so, wie die Architektur, für die sie den Code übersetzen. Weitere Details zur Hardware-Architektur bekommt der Compiler dann über weitere Optionen mitgeteilt (z.B. mit -mcpu).
Timo -- Meine Beiträge sind unter CC-BY-SA freigegeben

Antworten