Pages: 1 [2] 3 4 ... 7 
|
 |
|
|
Author
|
Topic: Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen (Read 10243 times)
|
|
DF8OE
Administrator
 Offline
Posts: 6268
Stellvertr. OVV I40, Jugend / Nachwuchsreferent
 
|
 |
Wer macht mit bei Firmware-Erweiterungen?
« Reply #15 on: 31. August 2015, 07:36:27 »
|
|
Hallo liebe OMs,
nachdem der Bau der Firmware nun mit Eclipse und CoIDE möglich ist, möchte ich durchstarten, auch wenn es noch keine Zusammenführung mit den Änderungen von Clint gibt. Ich denke, dass (wie so oft) erst Tatsachen die Notwendigkeit einer gemeinsamen Github-Quelle aufzeigen werden...
Daher suche ich Mitstreiter, die an der Firmware mit bauen und evtl. einige Codeschnipsel beitragen können. Meine Idee für die erste Erweiterung ist die Aktivierung des Touchscreens. Dieser wird via SPI angebunden und ich würde es gut finden, wenn durch "Antippen" einer Stelle auf dem Spektrum / dem Wasserfall die Abstimmung dorthin springt - Feintuning kann man dann ja wieder mit dem Tuningknopf machen. Auch wäre es evtl denkbar, durch waagerechtes Streichen über Spektrum oder WF "stufenlos" über den überstrichenen Bereich abzustimmen...
Bitte meldet euch, wenn ihr Interesse habt!
Vy 73
Andreas
|
|
 Logged
|
Wenn der Wind des Wandels weht, nageln die einen Fenster und Türen zu und verbarrikadieren sich. Die anderen gehen nach draußen und bauen Windmühlen...
qrz.com-Seite von DF8OE
-----------------------------------------------------
>>>> Die Inhalte meiner Beiträge dürfen ohne meine explizite Erlaubnis in jedwedem Medium weiterverbreitet werden! <<<<
|
|
|
dg0nf
OM_nicht_I40
noch länger dabei
Offline
Posts: 132
OV V30 - Wolgast/Insel Usedom
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #16 on: 31. August 2015, 07:49:57 »
|
|
Moin Andreas!
Ich würde zwar rein theoretisch mitmachen, aber leider habe ich im Moment wieder mal ein Zeitproblem, so dass ich erstmal andere Prioritäten setzen musste. Sollte meine Zeit es wieder zulassen, bin ich dabei, wenn auch sicherlich nicht so extrem aktiv. Wenn es aber darum geht, mal irgendwas auszuprobieren, das geht eigentlich immer irgendwie.
73, Helge (DG0NF)
|
|
Logged
|
|
|
|
|
|
DF4KD
schon länger dabei
Offline
Posts: 55
Ich liebe dieses Forum!
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #18 on: 31. August 2015, 12:27:53 »
|
|
Hallo Andreas,
grundsätzlich würde ich mitmachen. Allerdings muß ich mich erst wieder einarbeiten da ich schon seit einigen Jahren "raus" bin (sicher schon gemerkt bei meinen Eclipse Fragen). Auch habe ich noch keine HW. Die ist aber schon angepeilt wird aber noch ein paar Wochen dauern, wegen wichtiger Zeitplanung (Urlaub, hi).
Wir werden dann wahrscheinlich zu zweit (DK8SJ und ich) versuchen etwas beizutragen...
73, Hans (DF4KD)
|
|
Logged
|
|
|
|
hbtron
Neuling
Offline
Posts: 22
Ich liebe dieses Forum!
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #19 on: 01. September 2015, 20:03:05 »
|
|
Zunächst: dieses Projekt fasziniert ! Wer einmal den ui_driver.c quer gelesen hat, weiß, wieviel Arbeit
darin steckt. Hoffentlich geht Alles mit rechten Dingen zu: Ich hatte keine Lust bei Yahoo etwas
über mich preis zu geben um an die Quellen zu kommen, ich habe die Quellen aus dem GIT von Andreas geholt.
Auch Inbetriebnahme-Doku usw. muss man wohl bei Yahoo holen. Material ist für mich kein Problem, allerdings
wären die Leuiterplatten-Gerber-Daten für ein echtes Open-Source-Projekt auch interessant, aber das gehört in eine andere Rubrik.
Ich habe zwar nicht die Absicht, die Firmware zu ändern, aber ich wollte mich, bevor ich das
Projekt als Pseudo-Rentner in Angriff nehme, von der Qualität der Sourcen überzeugen.
Da ich aber kein Freund von GUI's bin (ich habe mich 1998 von OS/2 verabschiedet, seitdem
ist Linux das OS meiner Wahl und das hauptsächlich auf der Kommandozeile) habe ich mir die Mühe gemacht, ein Makefile zu schreiben.
Leider funktioniert es nicht:
Wenn -nostdlib gesetzt ist , beschwert sich ld über fehlendes memset() und _impure_ptr_ sowie
über fehlende Funktionen, die innerhalb der Projekt-lib/libm.a (Funktion sqrt()) aufgerufen werden.
Wenn -nostdlib weggelassen wird, hagelt es beim Linken Fehler, die die VFP-Register betreffen.
Die Version des gcc ist sicher nicht das Problem (ich habe 9.3q1 und 9.3q2 versucht), sicher auch nicht das
Windows oder Linux. Ich habe harte Pfade zum gcc im Makefile eingetragen. Schon beruflich muss
ich 4 GCC-Versionen auf meinem Arbeits-PC vorhalten, da bleibt mir kaum Anderes übrig.
Wenn Interesse besteht, stelle ich das Makefile gerne zur Verfügung (wohin posten ?) . Der Kompiliervorgang zeigt jedenfalls jede Menge Warnings, die hauptsächlich den Vergleich signed/unsigned betreffen. Auch fehlende Funktionsdeklarationen werden angezeigt - so etwas würde ich weder beruflich noch privat stehen lassen.
Im Gegensatz zu Eclipse kommen bei einem Makefile-Projekt nachvollziehbar immer die gleichen Warnungen bzw. Fehler.
Die fraglichen Linker/Compiler-Optionen sind:
CFLAGS = -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -mthumb -ffunction-sections -fdata-sections -O3 -flto \
-DARM_MATH_CM4 -DSTM32F407VG -DSTM32F4XX -D__FPU_USED -D__FPU_PRESENT -DUSE_STDPERIPH_DRIVER -D__ASSEMBLY__ -c -W -Wall
LDFLAGS := -nostdlib
LIBS := -Llibs -larm_cortexM4lf_math -lm
Die Defines habe ich dem Eclipse firmware.coproj entnommen.
Hat jemand eine Idee ?
vy 73,
Harald, DL4SAI
|
|
Logged
|
|
|
|
DF8OE
Administrator
Offline
Posts: 6268
Stellvertr. OVV I40, Jugend / Nachwuchsreferent
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #20 on: 02. September 2015, 06:26:13 »
|
|
Hallo Harald,
ich habe im Prinzip erst "an der Oberfläche" der Firmwaresourcen gekratzt - aus Zeitmangel. Ich arbeite seit 15 Jahren ausschliesslich unter "Linux". Vieles mache ich auf der Konsole - weil es dort wesentlich einfacher und schneller geht. Aber ich nutze auch die GUI - eben je nach Aufgabenstellung.
Das Problem dürfte im Linker liegen. Es war mir praktisch auf Anhieb gelungen, mit dem gcc die einzelnen Quellen zu kompilieren - aber der Linkvorgang (auch wegen der beiden externen Libs) schlug auf Anhieb fehl. Hier musste etwas Handarbeit folgen. Genauso dürfte das mit dem Erstellen des makefiles aussehen. Ich werde mir diese "Baustelle" aber nicht vornehmen 
Sicher wäre es ein Ziel, die Warnings zu eliminieren. Aber selbst darin liegt zumindest bei ein paar schon ganz schön viel Arbeit. Ich zögere im Moment mit der Investition von Zeit, da ich das nur tun würde, wenn es eine gemeinsame Basis gibt.
Zum Thema "Open-Source":
Chris hat eine "eigenwillige Lizenz" gewählt. So eine Mixtur aus "Frei" und "unfrei" (z.B. sind die Platinen-Gerbers nicht frei und auch der Sourcecode des Bootloaders nicht). Das ist halbherzig - aber da können wir nichts dran ändern. Fakt ist auf jeden Fall, dass so weite Teile, wo wir "richtig was ändern können", definitiv offfen sind und daher Änderungen realisiert werden können.
vy 73
Andreas
|
|
Logged
|
Wenn der Wind des Wandels weht, nageln die einen Fenster und Türen zu und verbarrikadieren sich. Die anderen gehen nach draußen und bauen Windmühlen...
qrz.com-Seite von DF8OE
-----------------------------------------------------
>>>> Die Inhalte meiner Beiträge dürfen ohne meine explizite Erlaubnis in jedwedem Medium weiterverbreitet werden! <<<<
|
|
|
hbtron
Neuling
Offline
Posts: 22
Ich liebe dieses Forum!
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #21 on: 02. September 2015, 07:12:21 »
|
|
Hallo Andreas,
ok, dann werde ich mich mal auf die Suche machen, woher diese libarm_cortexM4lf_math.a
und libm.a im Verzeichnis lib stammen und ob ersichtlich ist, wie sie zustande gekommen ist.
Meistens stammt so etwas aus Beigaben zu einem Eval-Board von ST und ist dann bereits
in die Jahre gekommen...
vy 73.
Harald
|
|
Logged
|
|
|
|
DF8OE
Administrator
Offline
Posts: 6268
Stellvertr. OVV I40, Jugend / Nachwuchsreferent
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #22 on: 02. September 2015, 07:58:34 »
|
|
Das ist bestimmt so eine "Leiche". In den Originalsources, die auch Clint mit "CoIDE" bearbeitet, sind noch viele andere Leichen. So auch zwei Bibliotheken, die bisher jedem FW-Update getrotzt haben aber niemals eingelinkt wurden. Auch waren einige C-Dateien zwar mit im Ordner - aber funktionslos. Haben nur "in der Luft schwebenden Code" erzeugt, der keine Verwendung hatte (und auch keinen Zukunftsbezug). Nach Entfernen dieser Kröpfe war die FW schon mal rund 50kb kleiner und auch schneller - warum auch immer. Ich würde es sehr gerne sehen, wenn hier aufgeräumt und geordnet werden würde...
Ich bin gerade dabei, die Unterschiede zwischen dem alten Display und dem neuen in Sachen "SPI-Belegung" herauszubekommen. Mit einer Ansteuerung auf SPI-Basis hätten wir auf einen Schlag jede Menge freier GPIOs, die man für andere Aufgaben dringend gebrauchen könnte. Leider ist der Code nur teilweise dokumentiert, und vieles ist "seltsam". So habe ich z.B. herausgefunden, dass sich die Pinbelegungen für die Signale SDI, SDO, CS und CLK für den SPI-Bus geändert haben. Wäre ja auch nicht weiter schlimm - einfach ein paar Pins umdefinieren und dann sollte das wiedr laufen. Um kompatibel zu bleiben, könnte man ja zunächst auf "alte Version", dann auch "neue Version" testen und wenn beides fehlschlägt parallel-Ansteuerung nutzen. Nur liegt im Quellcode LCD_SCK auf GPIO-B, und der ist überhaupt nicht zum Display hin verdrahtet. Also wird der Clock entweder gar nicht gebraucht, oder die Namensgebung stiftet Verwirrung, oder, oder oder
Die frei werdenden GPIOS könnte man für die Nutzung der Tocuhfunktion verwenden (den vorhandenen SPI-Bus zum rf-Board nutzen plus eine Leitung für den Interrupt bei anliegenden TP-Daten). Da hier keine Riesenmengen an Daten anfallen, dürfte ein SPI-Bus für alle zukünftigen Devices zuzügl. TP-Funktion völlig ausreichen. Nur müsste man wie gesagt durch den COde soweit durchsteigen bzw. ein altes DP haben. Bevor ich hier stundenlang suche, würde ich einfach mal frech den SCK-Pin trennen und schauen, ob das DP immer noch läuft  Ich verwende unterschiedlichste Methoden für ein effektives Weiterkommen - auch sowas "stumpfes" gehört dazu. Nur habe ich kein altes DP 
vy 73
Andreas
|
|
Logged
|
Wenn der Wind des Wandels weht, nageln die einen Fenster und Türen zu und verbarrikadieren sich. Die anderen gehen nach draußen und bauen Windmühlen...
qrz.com-Seite von DF8OE
-----------------------------------------------------
>>>> Die Inhalte meiner Beiträge dürfen ohne meine explizite Erlaubnis in jedwedem Medium weiterverbreitet werden! <<<<
|
|
|
hbtron
Neuling
Offline
Posts: 22
Ich liebe dieses Forum!
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #23 on: 02. September 2015, 08:57:18 »
|
|
Hallo Andreas,
eigentlich sollte ich jetzt Geld verdienen, aber es lässt mir keine Ruhe.
zum Display bzw. Port-Problem:
Das Bild des Display bei hotmcu.com zeigt, dass man das Interface auf der
Display-Platine mit den 3 0-Ohm-Rs einstellen kann. Das bezieht sich auf die B-Variante.
Wenn 16-Bit gewählt ist, verstehe ich nicht, warum auf dem UI R30, R31 und R32 bestückt sein sollen.
Rein gefühlsmässig würde ich sagen, dass die Display-Ansteuerung über SPI ein zu großer Kompromiss in Bezug
auf die Update-Geschwindigkeit ist. Aber es würde nach Software-Änderung ja auch das 8-Bit-IF funktionieren.
SPI-FIFO und schneller SPI-CLK wären zwar eine Diskussion wert, aber dann während Runtime wohl ausschließlich
für das Display.
Mit 8-Bit-IF wären SPI mit ein paar CS + Interrupt für den Touch und anderes frei, wenn ich nichts übersehen habe.
Überhaupt fehlt wenigstens ein 'Options-Schieberegister' am SPI, das man im Anlauf in der FW auswerten
könnte, um kompatible Software zu alten Hardware-Konfigurationen schreiben zu können.
Ich weiß, hinterher ist man immer schlauer...
vy 73
Harald, DL4SAI
|
|
Logged
|
|
|
|
|
|
hbtron
Neuling
Offline
Posts: 22
Ich liebe dieses Forum!
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #25 on: 02. September 2015, 15:01:22 »
|
|
Hallo Andreas,
wenn man alles für ein Redesign in Frage stellt, wäre vielleicht zu überlegen, für
die 14 Tasten einen PCA8575DB (im SSOP24, RM 0.65) zu spendieren.
Dieser hat einen Interrupt-Ausgang (on Input change), der kommt erst, wenn eine Taste
gedrückt oder losgelassen wird. Die Programmierung ist zwar nicht so trivial, spart aber jede Menge Ports.
Man könnte den PCA8575 am I2C des EEprom anschließen, damit die Ansteuerung des Si570 und
des Temp.-Sensors nicht geändert werden muss.
Mit schnellem SPI wäre ich vorsichtig, den bekommt man sicherlich im Empfänger zu hören.
Wenn man das in der jetzigen Hardware zum Laufen bringt, wäre es sicher richtig, das erst
mal zu testen. Der Touch hat wohl einen Interrupt-Ausgang, da könnte man eine (langsame) extra SPI
anwerfen, sobald 'getoucht' wird.
Bezüglich Bootloader: ich habe ganz übersehen, dass das Binary nicht an Adresse 0 gelinkt wird, sondern
ab 0x08010000 (deine .map).
Aber eigentlich müssen doch alle, die das Gerät bauen, für das erste 'Flashen' den eingebauten Bootloader über
USART1 oder 3 nutzen oder eine Hardware mit Single-Wire-Debug besitzen. Der Bootloader über USB-OTG als
Device ist doch reiner Luxus. Ich habe so etwas letztes Jahr für NXP Cortex-M3 gebaut (komerziell, absoluter
closed Source, mit Code-Read-Protection).
Aber Bevor ich hier dumme Fragen stelle, warte ich erst mal deinen 2. Artikel im FA ab.
vy 73,
Harald DL4SAI
|
|
Logged
|
|
|
|
DF8OE
Administrator
Offline
Posts: 6268
Stellvertr. OVV I40, Jugend / Nachwuchsreferent
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #26 on: 02. September 2015, 15:13:43 »
|
|
Ja, den GPIO I2C kenne ich...
Ich werde das mit dem SPI und dem Display mal testen. Ich denke, das geht doch einfacher als zunächst angenommen. Es bewahrheitet sich mal wieder, dass man erst die Informationen sammeln sollte und dann loströten
Schraube Deine Erwartungen an den zweiten Artikel nicht allzusehr in Detailinfos. Wären diese auch nur halbwegs vollständig, würden sie den Rahmen selbst eines Mega-Artikels bei Weitem sprengen. Deswegen habe ich mich ja auch zu einem Buch entschieden - da bestimme ich selbst den Platz.
Außerdem sind viele Dinge, die für Verbesserungen angedacht werden können, so komplex, dass sie den technischen Background vieler OMs ebenfalls übersteigen würden. Der artikel sollte auch in der zweiten Ausführung eine möglichst breite Zielgruppe von Lesern ansprechen 
vy 73
Andreas
|
|
Logged
|
Wenn der Wind des Wandels weht, nageln die einen Fenster und Türen zu und verbarrikadieren sich. Die anderen gehen nach draußen und bauen Windmühlen...
qrz.com-Seite von DF8OE
-----------------------------------------------------
>>>> Die Inhalte meiner Beiträge dürfen ohne meine explizite Erlaubnis in jedwedem Medium weiterverbreitet werden! <<<<
|
|
|
hbtron
Neuling
Offline
Posts: 22
Ich liebe dieses Forum!
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #27 on: 04. September 2015, 13:56:15 »
|
|
Hallo Andreas,
ich habe herausgefunden, dass 'libarm_cortexM4lf_math.a' eine umbenannte 'arm_cortexM4lf_math.lib' ist.
Woher diese stammt (Fa Keil ??), ist mir nicht ganz klar.
Die libm.a im Verzeichnis libs besitzt die gleichen Funktionen, die die libm.a der gcc-toolchain mitbringt.
Die 'richtige' libm.a liegt wohl im Verzeichnis 'arm-none-eabi/lib/armv7e-m/fpu/libm.a' der Toolchain.
Das sollte man dem Linker irgendwie klar machen können (-L...)
Vielleicht kannst du wenigstens diese 'Krücke' entsorgen.
Ich bekomme aber beim Linken mit meinem Makefile noch 2 Fehler, die wirklich im Code liegen:
usb/otg/src/usb_core.o: In function `USB_OTG_ActiveRemoteWakeup':
usb_core.c:(.text.USB_OTG_ActiveRemoteWakeup+0x32): undefined reference to `USB_OTG_BSP_mDelay'
usb/usbd/class/audio/src/usbd_audio_out_if.o: In function `MuteCtl':
usbd_audio_out_if.c:(.text.MuteCtl+0x2): undefined reference to `EVAL_AUDIO_Mute'
collect2: error: ld returned 1 exit status
Beim ersten Fehler hat jemand das Macro umbenannt und den Kommentar noch stehen gelassen:
USBH_OTG_BSP_mDelay() gibt es in /drivers/keyboard/usb/usbh_bsp.c. Das müsste eclipse
eigentlich auch anmeckern.
Für das 2. Macro finde ich überhaupt keine Definition.
Kommt dir das irgendwie bekannt vor ?
vy 73,
Harald, DL4SAI
|
|
Logged
|
|
|
|
DC3AX
Interessent
noch länger dabei
Offline
Posts: 186
Ich liebe dieses Forum!
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #28 on: 04. September 2015, 14:27:21 »
|
|
Hallo Andreas, hallo Harald,
vielleicht ist es wirklich am Besten, wenn wir uns zunächst auf die bestehende Hardware konzentrieren und abgesehen von den zwingend notwendigen Änderungen darauf verzichten, die Software und die Hardware gleichzeitig zu ändern. Schon garnicht in einem Thread in diesem Board.
Wie ich zuvor schon geschrieben habe, sind die Einstellungen von verschiedenen Eclipse Versionen unter verschiedenen Betriebssystemen und verschiedenen Add-Ons (x-gcc, y-gcc, bla-avr, blubb-stm) nicht übertragbar. Um das Ganze wirklich portierbar zu machen, ist ein Makefile das Einzige was funktioniert.
Ich würde gerne am Makefile mitarbeiten, daher wäre es schick, wenn man das schon mal irgendwie einchecken oder anderweitig herum reichen könnte. Ich würde allerdings ein normales Arbeiten auf github bevorzugen, wo jeder forken kann und man sich trotzdem gegenseitig die Änderungen oder Fortschritte zuschubsen kann.
Das lib-chaos ist sicherlich leicht zu beheben, das signed-unsigned und die anderen warnings wird man recht leicht los, wenn man das makefile mit den entsprechenden compiler-options so scharf schaltet, dass Warnings im Release Code mit Errors gleichgesetzt werden. Man kann sauberes Programmieren auch ein wenig erzwingen 
Nachtrag:
Ich hatte den USB-Loader immer für die Einfachste Option gehalten, weil man ohne Programmieren von Treibern auch dann die Firmware flashen kann, wenn man reiner Anwender ist. Extra noch einen Loader für die Serielle schreiben ist auch nicht die Lösung, da das wieder ein Serielles Kabel oder alte Rechner resp. Notebooks verlangt.
Mal schauen was da geht...
73!
Ulrich
|
| « Last Edit: 04. September 2015, 14:30:09 by Astralix » |
Logged
|
Es gibt drei binäre Zustände: Ein, Aus und Vielleicht. Je höher die Frequenz, desto Vielleicht...
|
|
|
DF8OE
Administrator
Offline
Posts: 6268
Stellvertr. OVV I40, Jugend / Nachwuchsreferent
|
|
Re:Firmware lässt sich nun mit "Eclipse" anstelle von "CooCox" bauen
« Reply #29 on: 05. September 2015, 06:46:59 »
|
|
Hallo Ulrich,
ich hatte die Portierung der Einstellungen auf meinem alten Eclipse Luna durchgeführt. Erst später habe ich dann bemerkt, dass es inzwischen "Mars" gibt.
Du schriebst, dass die Einstellungen schon bei kleinsten Änderungen nicht mehr passen.
Dann habe ich wohl grosses Glück gehabt oder der Zufall war auf meiner Seite - denn bei mir passten die in meinem github hinterlegten Einstellungen und Sourcen SOFORT auf Eclipse Mars
Auch gelang es mir reproduzierbar, mit den Anweisungen aus dem vierten Post in diesem Thread Eclipse auf verschiedenen Umgebungen zu installieren und das Projekt erfolgreich zu bauen.
Dass man das Plugin gnuarm braucht (das gleich eine Reihe anderer Plugins nach sich zieht), ist ja logisch. Man will ja auch für einen Arm-Prozessor bauen...
Ein Makefile ist sicher eine gute Sache. Aber wenn man sich umblickt und einfach nur realisiert, wie viele Leute auf Linux und dort rein auf der Konsole arbeiten, wird das Feld schon recht dünn.
Eine große Community bekommt man aber nur hin, wenn man möglichst wenige (im Idealfall keinen) "aussperrt". Und da die meisten eben mit einer GUI-IDE arbeiten, ist Eclipse, da für alle Welten verfügbar, sicher eine gute Lösung.
Ich würde mich auch freuen, wenn wir zunächst gemeinsam an der Verifizierung arbeiten, ob man das Projekt z.B. auch mit Windows und Eclipse mit den Dateien aus meinem Guthub bauen kann. Aber erstens habe ich keinen Rechner mit Windows auf dem ich einfach mal probieren kann und zweitens hat auch mein Tag nur 24 Stunden Zeit und dummerweise muß ich einen recht erheblichen Tag davon sinnfreie Dinge tun (== Geld verdienen). Das Projekt ist also auf die konstruktive Mitarbeit vieler angewiesen!
Der erste Teil einer Arbeitsteilung wäre z.B., dass sich jemand bemüht, ein Makefile zu erstellen. Damit hätten wir wieder mehr potentielle "Mitbauer". "noch gesucht" probiert mal, ob er auf einem Windows Eclipse installieren kann und mit den Dateien von meinem Github das Projekt bauen kann. Ein weiterer "Unbekannt" tut das unter OS-X. Damit wären wir schon einen grossen Schritt weiter!
Ich habe mir mal die "Warnings" gestern genau angesehen. Zu etlichen gibt es bereits Bugreports auf Sourceforge beim gcc. Ich frage mich, wie man darauf kommst, dass diese "warnings" aufgrund unsauberer Programmierung entstanden sind. Noch vor Monaten waren es über 50 Warnings - da hat Clint mit seinem CoIDE die "echten Schnitzer" wohl schon grösstenteils gefunden und eliminiert.
Ich für meinen Teil vertrete die Ansicht, dass das Verhältnis für den Zeitaufwand zum Suchen der Ursache für eine solche Warning in einem gesunden Verhältnis zur blossen Tatsache, dass ich eine Zeile nun NICHT mehr sehe, stehen muß. Vorrangig ist doch, dass das gebaute Binary lauffähig ist - und das ist es.
Einige Warnings stammen auch daher, dass die verwendeten Libs Variablennamen benutzen, die "unüblich" und daher reserviert sind. Daher kommen einige "redefined..."
Wer meint, die Libs seihen zu verbessern: Kein Ding! Wir alle freuen uns, wenn es jemand geschafft hat, das auf anderen Libs aufzubauen. Spannend wäre dann noch, ob die FW dadurch Vorteile hätte wie:
- weniger CPU-Last
- schnellere Abarbeitung zeitkritischer Abläufe
- kürzerer Code
Wenn eines oder mehrere davon eintreten, wäre das ein grosser Fortschritt. Wenn nicht, war das ganze ABM.
Konkret werden Leute gesucht, die verifizieren, ob sie das Projekt auf "ihrem PC" mit Eclipse nun auch bauen können - und wenn nicht, sollte wir herausfinden, WARUM NICHT. Wenn die Lösung einfach ist, editiere ich einfach meinen Eintrag (4) und dann gelingt es vielleicht immer mehr?!
vy 73
Andreas
|
Wenn der Wind des Wandels weht, nageln die einen Fenster und Türen zu und verbarrikadieren sich. Die anderen gehen nach draußen und bauen Windmühlen...
qrz.com-Seite von DF8OE
-----------------------------------------------------
>>>> Die Inhalte meiner Beiträge dürfen ohne meine explizite Erlaubnis in jedwedem Medium weiterverbreitet werden! <<<<
|
|
|
Pages: 1 [2] 3 4 ... 7 
|
|
|
|
|
|
|
Mit einer Matrix 3x5 ließe sich die Menge der Ports immerhin auf 8 reduzieren, also 6 wichtige Ports gewonnen 
