Eclipse Plugin für Fujitsu 16bit µcs

Version 0.0.2 hat jetzt auch einen eigens angepassten ErrorParser.

Die Sache mit der library hab ich gefixt und noch etwas anderen 
Kleinkram.

Das - steht absichtlich davor. Es sorgt dafür, dass make den returncode 
des Compilers ignoriert. Make erwartet da wohl 0 für fehlerfreie 
Ausführung, der Compiler spuckt aber irgendwas anderes aus, so dass make 
sonst nicht durchläuft. Zugegeben keine schöne Lösung.

Zu dem Pfadproblem: Keine Ahnung, bei mir tuts. Da gibts im Plugin auch 
nichts groß einzustellen. Dein Problem oben dürfte genau darauf 
zurückzuführen zu sein. Nämlich wenn der Compiler den Assembler aufrufen 
will, "fasm907s" an die Konsole schreibt und die nicht fündig wird.

Ansonsten hab ich hier zwar nen FX Chip, hatte aber nie einen LX in der 
Hand, von daher fehlt mir der Vergleich. Die ganzen Demoprojekte laufen 
bei mir auch mit dem Plugin, nur bei dem Stück an dem ich momentan 
arbeite spuckt mir der Linker noch ein paar nonsense Fehler.

flnk907s -cpu MB96F348TSA -g -w 1 -ra _INRAM01=0x002240/0x007FFF -ro 
_INROM01=0xF80000/0xFFFFFF -ro _INROM2=0xDF0000/0xDF7FFF -Xset_rora 
-check_rora -sc CONST/Const/BYTE=0xFF8000 -AL 2 -check_locate -m 
TSFW_Fujitsu.map -a -o "TSFW_Fujitsu.elf"  ./system/src/mb96348ts.o 
./system/src/start.o ./system/src/sys_clock.o ./system/src/sys_gpio.o 
./system/src/sys_it.o ./system/src/sys_main.o ./system/src/sys_ser0.o 
./modules/src/mod_clock.o ./modules/src/mod_io.o ./modules/src/mod_lcd.o 
./modules/src/mod_ser0.o ./modules/src/mod_test.o 
./core/src/core_assert.o ./core/src/core_cmdint.o ./core/src/core_com.o 
./core/src/core_lib.o ./core/src/core_main.o ./core/src/core_modload.o
*** obwrite.asm(47) E4305L: Unresolved external symbol (_write)
*** obwrite.asm(110) E4305L: Unresolved external symbol (_write)
*** obwrite.asm(172) E4305L: Unresolved external symbol (_write)
*** obwrite.asm(247) E4305L: Unresolved external symbol (_write)
*** obwrite.asm(305) E4305L: Unresolved external symbol (_write)
*** ocwrite.asm(24) E4305L: Unresolved external symbol (_write)
*** ocwrite.asm(71) E4305L: Unresolved external symbol (_write)
make: *** [TSFW_Fujitsu.elf] Error 2
make: Target `all' not remade because of errors.

Der Gag dabei ist, dass im ganzen Projekt bzw. auf dem ganzen Rechner 
keine Dateien namens obwrite.asm oder ocwrite.asm existieren. Und die 
große Frage ist, was der Linker überhaupt mit Assembler Dateien will. 
Bin für jede Idee dankbar.

Hallo Michael,
welches Speichermodell benutzt du? Versuch doch mal deine Sourcen mit 
der Compileroption "-model LARGE" zu übersetzen. Und gib dem Linker die 
richtige Lib mit.
Das ist im ersten Schritt vielleicht sehr bequem aber man muss nicht 
über alle Funktionen und oder externen Variabelen schauen ob sie mit 
near oder far initialisiert sind.
Hoffe der Tip nütz dir etwas.

Grus Niklas

Leider nicht. Hab damit etwas rumexperimentiert, aber der Fehler hält 
sich hartnäckig. Mal abwarten, was der Support dazu sagt.

Was mir noch nicht 100% klar ist, ist welche Bibliotheken genau benötigt 
werden. Eigentlich doch lib907x.lib mit x=l für LARGE und x=c für 
COMPACT. Da das Programm momentan nicht allzu groß ist, sollte die 
lib907c.lib zusammen mit -model COMPACT ausreichen. Btw. dafür werd ich 
auch noch ne Option ins Plugin bauen.

Hi Michael,
einige Hinweise zu den Librarys und den Namenskonventionen erhältst du 
im Compilerhandbuch Seite 125. Adressierung von Code und Daten Seite 61.

Ich bin glaube am Anfang auch über diesen Fehler gestolpert und zwar 
setzt sich dein Projekt aus mehreren Objects zusammen. Wenn Funktionen 
oder Variabelen adressiert werden passiert dass in Abhängigkeit vom 
Verwendeten Model.
Für das Large Model musst du die .../lib/907fx/lib904l.lib nehmen.
Probier das mit dem Model nochmal.

Mit welcher Softune Version arbeitest du? Und hast du das Library Update 
eingespielt?

Arbeite selbst mit V30L33R09 incl. Update von der Fujitsu Homepage

Hmm, update eingespielt, Speichermodelle probiert, alles mal unter 
softune laufen lassen - nichts. Ich wart immer noch auf die Antwort vom 
Support. Trotzdem danke für deine Mühe mit dem elenden Fehler.

Dafür hab ich noch kurz die Auswahl des Speichermodells mit ins Plugin 
übernommen.

Hört sich ja nicht so toll an, wenn selbst Softune meckert.
Sieht aber nach nem Lib Problem aus.
Hast du das SK-16FX-100PMC - Kit?
Verwendest du printf, fopen in deinem Projekt?
Habe mir mal das Template von deinem Kit angeschaut und mir ist 
aufgefallen, dass du deinem Linker den Pfad zu den 907fx Libs nicht 
mitgibst.
Vielleicht ist es das schon.

So jetzt hab ich ihn. Seltsamerweise wollte der linker einen stub für 
diese write-Funktion, obwohl ich weder printf, fopen noch irgend ne 
andere Funktion verwende, die über die stdio schreibt.

Das hört sich gut an. Der Weg mit Fujitsu ist manchmal steinig.
In der Datei start.asm gibt es den Punkt
4.7  Low-Level Library Interface
steht der Parameter auf ON?

Hast du die stub Funktion aus einem Beispiel? siehe 90xxx_sw_printf-v12 
auf der Samples-Seite von Fujitsu.

Ja ist off. Jetzt läuft alles. Und da der stub lediglich aus return 0 
besteht brauch ich da ned mal ne Vorlage ;)

hallo zusammen,
mir gehts wie dem kollegen oben, ich habe eclipse bisher auch noch nie 
verwendet und find die idee eclipse als IDE anstelle von softune zu 
nehmen eigentlich ganz charmant (softune ist ja wirklich keine 
schoenheit und auch nicht gerade komfortabel).
also drauf los und eclipse 3.3.0 und cdt 4.0 runtergeladen und 
installiert,
fujitsu-plugin eingebunden, demoprojekt (counter) von fujitsu 
hergenommen,
und ich bekomme auch immer nur die fehlermeldung:

(Exec error:Launching failed)

ich denke das einfach die makefiles nicht passen.

waere nett wenn ihr mal ein paar infos rausgeben koenntet, wie man denn 
eclipse generell mit dem fujitsu plugin verwendet und was man sonst noch 
so braucht (ggf. GNUmake, ...)

Danke

As I mentioned in my last posts, I'm not working on this project 
anymore. I don't even have compilers and chips for working on it, even 
if I wanted. Maybe kalinka has an running version now? He had asked me 
for details before.

Sorry, that I can't help.

hallo zusammen,
ich habe auch keine zeit mehr fuer das plugin aufgewendet!
Softune ist zwar ein reudiger editor, aber man gewoehnt sich dran.
sorry, plugin RIP!

C-YA

Hallo Michael Löffler!

Kannst du mir vielleicht verraten wo man Infos zum Plugin-Bau für 
Eclipse findet? Suche schon eine ganze Weile nach einer Doku oder etwas 
Vergleichbarem.
Auf der Seite www.eclipse.org findet seit geraumer Zeit schon kein 
Mensch mehr was.

Gruß
Mandrake

Hi Dan,

I think you have to change the output format from ELF to ABS.
This setting can be found at:
C/C++ Build->Settings->Build artifact-> Artifact extension

At the moment I have the problem that the linker is not working. I 
always get the error message:
*** ..\init.c(116) E4305L: Unresolved external symbol (_config)

Config is a structur which is defined in my code. I think something is 
missing or wrong in the linker settings, but I don't know what. Any 
clue?

Regards
Thomas

Hey there Felix!

Is it you supporting this project now?

I am quite interested in it, though I haven't tried it yet. Softune is 
used in my company as debugger and compiler, whereas UltraEdit is used 
to write the code. I have used the YAGARTO toolchain before and came to 
like Eclipse but alas...no 100% working plugin...

If you plan on starting a new thread it would be nice if you could log 
in as a real user so that it is possilbe to reach you easier :)

greets

E-Lore

so is this Project and / or the thread dead now?

very good...I'll try it out as soon as I got some time! :)

Hallo Felix
Das Plugin 1.0.1 arbeitet eigentlich nicht schlecht. Habe es mit LX 
(MB90F497) und FX (MB96F346) getestet.

Einige Hinweise:
-FETOOL=C:\Programme\Softune in Environment Table setzen
-INC907=C:\Programme\Softune\lib\907\include in Environment Table setzen
-*.ASM and *.C Files werden, falls gross geschrieben nicht erkannt.
-Makros für die CPU Definition setzen z.B. _CPU_MB96F346_

Aufgetretene Probleme:
-Verlust aller Einstellungen beim Schliessen des Projekts oder von 
Eclipse
-Der Eclipse Indexer will nichts von den definierten Makros innerhalb 
des Plugins wissen. Wie kann ich dem Indexer die Makros beibringen, 
damit ich CPU-Varianten-Kompilation verwenden kann ? Variablen setzen 
und so hat bis jetzt nicht funktioniert.

Gruss Daniel

Dear Hassan,
you should check Fujitsu's website:
http://mcu.emea.fujitsu.com
where you can find a lot of software examples:
http://mcu.emea.fujitsu.com/mcu_product/mcu_all_software.htm

Related to your question you should check the example
"96xxx_sw_printf-v10.zip"

Of course you have to define your low-level output function ... write()
otherwise where should printf send your data.
By the way. You should be very carefully using the printf within 
embedded software, as this powerful function requires a lot of memory on 
the stack.

Further, Felix is right, your topic has nothing to do with Eclipse,
so should normally open a new topic for new questions ;-)

With best regards,

MicRoller

Hi FrankB,
Deine Anfrag eist etwas offTopic, daher jetzt schnell eine Antwort, 
damits dann wieder mit Eclipse weitergehen kann ;-)

Ein Blick in die Online-Hilfe (Menue: HELP) bringt schnell die Lösung:

W1711A: [Program action] Continues processing with the specified 
address.

Wie sie im start.asm sehen können, werden die Adressen der I/O-register 
explicit mit .ORG gesetzt.
Dies ist also nur eine Warning, um anzuzeigen, dass manuell der 
Addresscounter manipuliert wird.
'Standardmaessig' werden diese Warnings in Fujitsu's Template-Projekten 
nicht ausgegeben, (Assembler-WarningLevel=2) Sie können die 
"Empfindlichkeit" der Warnungsausgabe aber beeinflussen, und das haben 
sie wohl auch getan.
Dabei erhalten sie mit Level=3 mehr Information, mit Level=0 keine 
Warnings.
Bitte überprüfen sie ihre Einstellung im Menue ==> Project / 
Setup-Project / Assembler

Hier auch der Link zum aktuellen Template inkl. Headerfiles
http://mcu.emea.fujitsu.com/document/products_mcu/mb90385/swb_samples/90385_template-v16.zip

Gruß, Toemi

Hi Alex und Felix,

erstmal muss ich sagen, dass das ne echt Klasse Sache ist mit dem 
Plugin. Eclipse ist nunmal als Entwicklungsplattform um einiges 
angenehmer als Softune ;)

Möchte aber dennoch gerne ein paar Punkte ansprechen:
in dem Plugin ist nach wie vor der Fehler mit dem erstellen von 
Libraries enthalten. Dh, wenn man eine Static Lib erstellen will die 
mehrere C-Files enthält meckert der Linker, weil er erwartet, dass die 
einzelnen Object-Files mit Komma getrennt übergeben werden, wohingegen 
diese bei dem Plugin mit Leerzeichen getrennt sind. Da wäre die Frage, 
ob man das irgendwie möglichst einfach beheben kann. In dieser Form sind 
zumindest die Libs nicht wirklich brauchbar.

Desweiteren wäre IMHO praktisch, wenn man per Default als Builder den 
Internal Builder vorgeben könnte, da unter Windows ja erstmal kein Make 
vorhanden ist. Cygwin nur für Make zu installieren ist doch etwas 
übertrieben ;)

Außerdem ist die Toolchain-Verwaltung meines erachtens etwas zu 
kompliziert. Natürlich muss man nur den gleichen Text an verschiedenen 
Stellen einfügen, aber das müsste doch auch so gehen, dass man es nur an 
einer Stelle einfügen muss? Eine andere Version dieses Plugins, die ich 
hier habe, macht sowas ähnliches über eine Oberklasse von der die 
einzelnen Tools erben (XML im Anhang). Also wäre nur in dieser 
Oberklasse der ganze Kram einzutragen und in den einzelnen Tools dann 
nichts mehr. Vielleicht liese sich diese Vorgehensweise ja adaptieren 
auf die Sache mit den mehreren Toolchains.

Kenne mich selber mit der Plugin-Entwicklung unter Eclipse leider gar 
nicht aus, sonst würde ich das ja selber mal angehen. Hoffe aber, dass 
ihr euch dieser Dinge annehmen könnt =)


Viele Grüße,
Chris

Nachtrag: (Edit meldet mir nur, dass ich das nich darf?!)

Bezüglich der Library-Sache müsste es doch eigentlich ähnlich wie das 
mit der LinkageOrder möglich sein? Also nen Stück Code, nur dass diesmal 
nicht InputResources geordnet werden, sondern zu einem String 
zusammengefasst und die einzelnen Elemente mit Kommas getrennt werden?

Soa, ich nochmal. Habe mir die ganzen Sachen mal angeschaut und den 
ersten (erstellen von Libraries) und zweiten Punkt (Internal Builder als 
Default) abgehakt. Nebenbei noch bei einigen Settings den Default-Wert 
verändert (obs generell Sinn macht weis ich nicht, für unseren 
Anwendungszweck in der Uni aber auf alle Fälle), so dass zB nicht 
soviele Dateien erstellt werden sondern nur das, was man braucht -> .o, 
.elf, .mhx

Den dritten Punkt (Einpflegen neuer Controller per Toolchain-Anpassung) 
habe ich zumindest teilweise gelöst. Dh, man muss nicht mehr in jedem 
der Tools Anpassungen durchführen, sondern nur einmal in einem 
Abstract-Tool am Anfang, und halt am Ende bei den 
Project-Configurations. Allerdings werde ich da nochmal beim 
AVR-Eclipse-Plugin abschauen, da sind die Dinge noch etwas anders 
gelöst.


Achja, Lösung zu Punkt 1 war, dass ich analog zur 
CommandLineGenerator-Klasse für den Linker eine für den Librarian 
erstellt habe, welche alle InputResources nimmt und mit "," zu einem 
String verkettet. Weis nicht, ob das die saubere Lösung ist, aber es 
funktioniert. Allerdings habe ich es dafür noch nicht geschafft, eine 
solche Library dann in einem Projekt zu verwenden (das ist mir 
allerdings auch mit Softune Workbench nicht gelungen). Bin aber schon 
mit Fujitsu in Kontakt deswegen ;)


Grüße,
Chris

Und da bin ich mal wieder. Hab in der Zwischenzeit einiges am Plugin 
rumgebastelt.


Neuerungen gegenüber dem letzten hier veröffentlichten Stand:
- Libraries sind komplett nutzbar

- Ein paar Project Settings sind hinzugekommen

- Converter nicht mehr per PostBuild-Step sondern als normales 
(optionales) Tool

- Integration für die Verwendung des alternativen Flash-Programmers 
"FLASHly"[1] von Holger Wech als zusätzliches optionales Tool (somit 
wird kein externes Flash-Tool benötigt)



Es hat aber noch ein paar Macken:
- Der Build von Anfang bis Ende (also inklusive Converter und FLASHly) 
funktioniert nur über ein Clean. Bei Build werden lediglich die 
Source-Files neu compiliert/gelinkt.

- Ab und an (vielleicht bei jedem 10. Versuch) wird beim Clean der 
Converter-Schritt ausgelassen -> FLASHly kann dann natürlich nicht 
arbeiten, da es kein mhx-File findet.

- Es gibt noch keine Möglichkeit, den Upload-Vorgang manuell über 
Toolbar oder Menü zu starten.



Da die plugin.xml in meinem ersten ja scheinbar schon von ein paar 
Leuten runtergeladen wurde hier nochmal der Hinweis, dass Feedback 
jeglicher Art sehr gerne gesehen ist. Das motiviert auch die weitere 
Arbeit meinerseits daran ;)


Chris


[1]: FLASHly und weitere Informationen zu 16[LF]X-Controllern: 
http://www.holgerium.de/elektronik/index.htm

Hi,

bekannt ist mir das Problem, allerdings bin ich bisher noch nicht soooo 
tief in der Materie drin, dass ich wüsste, wie ich das beheben kann. 
Wahrscheinlich müsste dafür der genannte Error-Parser weiterentwickelt 
werden, bisher habe ich ja nur am Toolchain-Teil gearbeitet.

Das ist aber definitiv noch ein Punkt, den ich angehen werde. Genau wie 
das Problem, dass er manchmal beim Clean nicht die eigentliche Toolchain 
sondern nur die SecondaryOutputs aufruft und kompilieren über Build 
meist nicht klappt ;)

Aber vielen Dank für dein Feedback. Werd mich hier auch wieder melden, 
wenns was neues gibt.

Grüße,
Chris

Keine Ahnung wann ich das verbockt hab, aber das ist nur die falsche 
Extension an der Datei ;)
Einfach in .lib umbenennen und gut ist.

Danke für den Hinweis, wird in der nächsten Version behoben sein.

Hallo,

Super Sache mit dem Fujitsu-Eclipse Plugin! Meine ersten Versuche haben 
auf Anhieb geklappt.
Seit einigen Monaten schlage ich mich nun mit Fujitsu-MCU's herum und 
möchte Eclipse mit dem Fujitsu Plugin vermehrt einsetzen. Dazu müsste 
ich jedoch noch einige Controller-Typen ergänzen.

Meine Frage: Ist es möglich den Quellcode des Plugins zu erhalten? (Habe 
bis jetzt noch keine Erfahrung mit Eclipse Plugins will mich jedoch 
einarbeiten).

Herzlichen Dank

Peter

Jein ... du hast ihn schon ;)
Der "Quellcode" besteht aus 2 Java-Dateien (Errorparser + 
Commandline-Generator für den Librarian) und einer grooooßen XML-Datei, 
die das eigentliche Plugin definiert. Alles ist in der Jar-Datei (ist ne 
ZIP mit andrer Dateiendung) ;)

Für neue Controllertypen sind in der XML die erweiternden Stellen schon 
mit Kommentaren markiert, sollten glaub 4 an der Anzahl sein.

Grüße,
Chris

@Christian

Danke für den Tipp! Na ja, die blutigen Eclipse-Plugin-Anfänger.

Habe mich bereits in der XML-Datei umgesehen und denke ich werde klar 
kommen.

Gruss,
Peter

Bin natürlich auch dankbar, wenn du die Erweiterungen weiterreichen 
könntest. Ziel ist irgendwann mal alle (zumindest die aktuellen) 
Controller zu unterstützen =)

Update zum Thema Zuverlässigkeit des Compile-Vorgangs: Scheinbar liegen 
die Probleme mit dem Aufruf der richtigen Teile der Toolchain wohl am 
(per Default in diesem Plugin genutzten) InternalBuilder von Eclipse. 
Den hatte ich eingestellt, da man für den ExternalBuilder zusätzlich zu 
Softune eben auch ein Make im System-PATH braucht. Hab das "heute" aber 
mal mit External ausprobiert und mir schien das zuverlässiger 
(allerdings noch nicht wirklich ausführlich getestet).


Wer also den ExternalBuilder nutzen will:
Folgende Teile von MSYS runterladen 
(http://sourceforge.net/projects/mingw/files/):
1. MSYS-Core (MSYS Base System -> Current Release_ MSYS-1.0.11 -> 
msysCORE-1.0.11-bin.tar.gz)
2. MSYS-Make (MSYS Base System -> Current Release_ MSYS-1.0.11 -> 
make-3.81-MSYS-1.0.11-2.tar.bz2)
Beides in ein Verzeichnis nach Wahl entpacken, zb C:\MSYS. Danach den 
MSYS\bin-Pfad an die Umgebungsvariable PATH anhängen: "...;C:\MSYS\bin".

Wenn man die Plugin-Version 1.1.0 nutzt: In Eclipse in den 
Projekteigenschaften unter C/C++ Build -> Tool Chain Editor auf "Gnu 
Make Builder" stellen.
In 1.1.1 ist dies standardmäßig eingestellt.



Änderungen in Version 1.1.1:
- Libraries bekommen wieder die Erweiterung .lib (nicht .elf)
- Standard-Builder ist ExternalBuilder (make). Internal ist aber nach 
wie vor manuell auswählbar
- Das Plugin erlaubt auch die Erstellung von Projekten unter 
nicht-Windows-Systemen (Nutzungsanleitung wird noch kommen, Flashen geht 
aktuell aber nicht direkt mit Linux)



Anhang: Version 1.1.1 des Plugins.


Grüße,
Chris

Nachtrag: Prinzipiell funktioniert die 1.1.1 zwar, allerdings klappt der 
Aufruf vom Librarian nicht mit GNU Make. Wer also Bibliotheken erstellen 
will, muss zur Zeit die Projekte noch mit dem InternalBuilder erzeugen.

Eclipse-Update-Seite für das Plugin:
http://fujitsu.chrilly.net/eclipse/updatesite/

Unter http://fujitsu.chrilly.net/ bzw evtl. der Unteradresse Eclipse 
wird es demnächst uU noch mehr Informationen geben, auf alle Fälle aber 
einen Bugtracker ;)


Grüße,
Chris

WICHTIGER HINWEIS:

Mit Version 1.1.9 (angepeilt für kommendes Wochenende) werde ich aller 
Voraussicht nach einiges am Kern des Plugins ändern, besonders was die 
internen ID's der XML-Nodes angeht (Cleanup, Vorbereitung für die 
Unterstützung der anderen uC-Serien von Fujitsu -> 8bit / 32bit). Ich 
befürchte, dass diese Änderung dazu führt, dass das Plugin dann die 
jetzt aktuellen Projekt-Einstellungen nicht mehr akzeptieren wird. Es 
müssten dann also folglich Projekte nach einem Update neu erstellt 
werden (aber in Anbetracht der nicht soooo umfangreichen Optionsliste 
dürfte die Neueinstellung ja recht fix von der Hand gehen).



Habe übrigens mal einen Bugtracker aufgesetzt in dem auch gerne fleißig 
Featurewünsche/Bugmeldungen eingetragen werden dürfen. Anonymen 
(lese-)Zugang gibt es aber erst ab heute Abend, da ich von meinem 
aktuellen Aufenthaltsort keine SSH-Verbindungen aufbauen kann ;)


Grüße,
Chris

Soa, 1.1.3 ist jetzt raus. Da sind primär kleine Updates enthalten, 
spezifisch die komplette 16FX-MCU-Unterstützung, Unterstützung des 
Sektor-Erase bei FLASHly, Typos meiner Vorgänger gefixt ;)


Allerdings kommen die geplanten größeren Änderungen erst mit dem 
nächsten Update, da ich meine Pläne etwas geändert habe und 2.0.0 ein 
komplettes Rewrite werden wird.


Grüße,
Chris

Hi Chris,
echt coole Sache, kann ich gut gebrauchen. Bin gerade umgestiegen auf 
die Fujitsu 16FX Bausteine.
Vielen Dank!

Gruss,
Microller

Hi Microller,

danke für dein Feedback, sowas kann man natürlich auch immer gebrauchen 
;)


@all: Gerade Version 1.1.4 hochgeladen. Damit sind nun quasi alle 
16-bitter die von Softune unterstützt werden integriert, inklusive der 
16LX. Dafür hat die XML-Datei nun auch ca 20.000 Zeilen (und davon max. 
1000 von den eigentlichen Tool-Defs und der Rest für die einzelnen MCUs 
;) ). Auch ein Grund, warum es da bald einen kompletten Rewrite geben 
muss.


Grüße,
Chris



/EDITH: Hab gerade gemerkt, dass ich natürlich als Basis für die 
Einpflegung der Controller das CSV von Dezember 2007 hergenommen habe. 
Wird also gegen Wochenende noch ein Update mit den aktuellsten Daten 
geben.

Hi Marco,
Schau dir mal die Appnote von Fujitsu an:
http://mcu.emea.fujitsu.com/document/appnotes/Public/16Bit/mcu-an-390049-e-s_format_adjuster/mcu-an-390049-e-v10-s_format_adjuster.pdf

Mit dem Tool Softune\bin\m2ms.exe kannst Du das ahx file erzeugen, und 
als Padding Data solltest Du dann 0x00 angeben (default ist glaube ich 
0xFF)

Wie Du das ganze aber in Eclipse einbindest, da kann ich dir leider 
nicht weiterhelfen.

Gruss,
Microller

Hi Marc,

> Wäre es kompliziert ein tool zu machen, der das konvertieren
> oder portieren kann?

Weis ich noch nicht, müsste ich mir mal anschauen, wie kompliziert die 
Projekt-Dateien von Eclipse aufgebaut sind. Was ich aber geplant habe 
für die Zukunft ist eine Import-Funktion um bestehende 
Softune-Projekteinstellungen zu übernehmen.


> Wie kann ich mit dem eclipse diese zusatz Funktion zu machen
> die im *.prj file ist, damit wir ein *ahx erstellen können ?

Du kannst in Eclipse "External Tools" eintragen, die man dann über die 
Toolbar / Menü aufrufen kann.

Folgendes habe ich gerade getestet und sollte so funktionieren ;)

1. Im Menü auf "Run" -> "External Tools" -> "External Tools 
Configurations ..."

2. Im linken Teil auf das Icon für "New launch configuration"

3. Oben rechts im Feld "Name" einen sinnvollen Namen für das Tool 
vergeben

4. Rechts im Feld "Location" die M2MS.EXE aus dem Softune-Ordner 
auswählen

5. Im Feld "Working Directory" "${project_loc}/Release" eintragen

6. Im Feld "Arguments" die gewünschten Parameter für M2MS eintragen, zb 
(aus deinem Beispiel) "-ran 0xFC0000, 0xFFFFFF -S2 -p 0x00", hintendran 
aber noch "${project_loc}/Release/${project_name}" hängen, also 
insgesamt "-ran 0x000000, 0xFFFFFF -S2 -p 0x00 
${project_loc}/Release/${project_name}"

7. In den Tab "Build" wechseln, die Box "The project containing the 
selected resource" auswählen oder die obere Checkbox ("Build before 
launch") deaktivieren (sonst wird immer alles im Workspace neu 
kompiliert)

8. In den Tab "Common" wechseln, in der "Display in favorites menu"-Box 
den Eintrag "External Tools" ankreuzen

9. "Apply" & "Close" anklicken

Nun kann man entweder wieder über "Run" -> "External Tools" -> (dein 
gewählter Name) oder über das Icon in der Toolbar das Tool aufrufen.


Unterstützung für den Adjuster werde ich vielleicht später auch mal 
direkt mit ins Plug-in einbinden.


Viele Grüße,
Chris

Hi Marc,

Marc schrieb:
> Gibt es bei Eclipse die Möglichkeit ein Komplette rebuild funktion?
Klar gibt es die Möglichkeit ;)
Mach im Project Explorer einen Rechtsklick auf das Projekt. Im 
Kontextmenü wählst du nun "Clean Project" aus (oder nur "Clean", weis 
grad nicht genau was da steht). Dadurch werden alle erzeugten Dateien 
gelöscht und der nächste Build-Vorgang kompiliert/assembliert/linkt alle 
Dateien neu.


Grüße,
Chris

Hi,

werde ich mir heute Abend mal beides Anschauen, eigentlich (dachte ich) 
hab ich das alles getestet ;)

Grüße,
Chris

Hi Sven,

habs mir nun mal angeschaut. Plugin manuell reinpacken hat bei mir 
problemlos funktioniert (aber beachten, dass auf der Updateseite nur die 
Feature-Pakete verlinkt sind, das sind nicht die Plugins, die gibts 
unter http://fujitsu.chrilly.net/eclipse/updatesite/plugins/ ).

Warum er bei dem Lizenzfenster hängt ist mir aber im Moment noch ein 
Rätsel. Werde dem aber noch nachgehen.


Grüße,
Chris

Komisch ... grad nochmal den Updatemanager gestartet und diesmal hat er 
die Lizenzbestimmungen angenommen. Geändert hab ich aber definitiv in 
der Zeit nix.

Hi scheeenk,

> super Plugin und gute Anleitung wie man das ganze zum laufen bringt.
Danke =)

> Der ErrorParser kennt __direct, __far, __interrupt usw. nicht und
> markiert diese Stellen dann als SyntaxError.
Hm, meines Wissens nach hat das nichts mit dem ErrorParser zu tun, da 
dieser glaub nur für das Auswerten der Meldungen der Toolchain da ist. 
Die Syntax-Errors die Eclipse anzeigt erzeugt Eclipse allerdings selber 
auf Basis des Wissens vom CDT-Plugin über die Sprache. Also müsste man 
dem wohl irgendwo beibringen, dass diese Attribute an den Stellen 
erlaubt sind.
Steht übrigens auch schon auf meiner ToDo für die nächste Version, muss 
nur noch rausfinden wie das geht ;)

Grüße,
Chris

Hi Daniel,

das ist natürlich auch eine Lösung. Auf sowas wäre ich gar nicht 
gekommen ;)
Allerdings sollte das natürlich bei ner sauberen Version des Plugins 
auch mal ohne gehen, immerhin ist das ein festes Sprachelement. Ist 
sicher irgendwie machbar, mal schauen wann ich dazu komme.

Grüße,
Chris

Hi,

zu den Präprozessormakros: Hab ich mir angeschaut und ich glaube ich 
habe es mit 1.1.7 gerade gefixt. D.h. es sollte sowohl unter "C/C++ 
General -> Paths and Symbols -> Symbols" möglich sein, Defines 
einzutragen die im Code nutzbar sind und auch in den Settings der Tools 
angezeigt werden als auch umgekehrt =)

Danke, Sven, für den Hinweis.


Andy schrieb:
> - in welcher Form müssen Object Files in der Linkage Order list
> eingefügt werden? Möchte vorerst keine Makefiles schreiben. Meine Object
> Files befinden sich in Ordnern... der Linker listet sie wie folgt:
> ./Src/main.o ./Src/uart.o ./Src/SPI.o,...
Linkage Order funktioniert zur Zeit auf Grund der Arbeitsweise des 
Makefile Generators von Eclipse noch nicht. Wird auch sicher noch einige 
Zeit dauern, bis ich das beheben kann (wahrscheinlich werde ich das erst 
mit dem kompletten Neubau des Plugins realisieren). Allerdings bist du 
nicht der Erste, der danach fragt. Also hat das auch einen festen Platz 
in meiner ToDo-Liste ;)

> - ich finde keine Infos was für Features in 1.1.5 und 1.1.6
> hinzugekommen sind?
Das leidige Thema Docu ... Eigentlich kam da nicht wirklich viel neues 
hinzu, im Prinzip war es nur die Unterstützung der ganzen Controller der 
16LX/FX Serie gemäß dem aktuellsten CSV-File von Fujitsu (1.1.5) und 
eine kleine Fehlerkorrektur was die Standardwerte für die 
Linker-Disposition anging (1.1.6), da dort bei 1.1.5 teilweise die 
falschen Flash/RAM-Bereiche eingetragen wurden.

Grüße,
Chris

Hi Andy,

zum internen Builder kann ich leider nicht viel sagen, da ich den schon 
seit Ewigkeiten nicht mehr benutzt habe ;)
Der macht nämlich manchmal auch Ärger, wenn man Daten geändert hat und 
dann nur nen kleinen Neubuild macht. Insgesamt hat sich bei meinen Tests 
ergeben, dass Make da einfach sauberer arbeitet. Wobei das vielleicht 
auch Umgebungsabhängig ist, aber zumindest auf ca 15 Pool-PCs in der Uni 
und meinen VMs verhielt sich das relativ ähnlich ;)

Grüße,
Chris

Ich kopiere meine Frage in Form eines links
Beitrag "Eigene Build/makeprozesse in Eclipse bauen"
und meiner Frage rein:
Wir arbeiten mit dem 32bit Prozessor und wollten schauen wie komplex es 
ist sowas für Eclipse zu bauen. Nun gibts das für 16bit und die 
Anpassung an 32bit dürfte nicht so schwer sein. Ich sah das du im 
Oktober vergangenen Jahres die 32 Bit Geschichte implementierne 
wolltest, wo bist du da denn angekommen?

Viele Grüße

Hi,

> Wir arbeiten mit dem 32bit Prozessor und wollten schauen wie komplex es
> ist sowas für Eclipse zu bauen. Nun gibts das für 16bit und die
> Anpassung an 32bit dürfte nicht so schwer sein.
Die reine Toolchain-Anbindung ist nicht sooo umfangreich ;)
Anpassung des bestehenden dürfte auch durchaus fix von der Hand gehen, 
je nach dem wie komfortabel das Ergebnis sein soll.

> Ich sah das du im Oktober vergangenen Jahres die 32 Bit Geschichte
> implementierne wolltest, wo bist du da denn angekommen?
Da hab ich noch nicht mit angefangen, da das auch erst mit V2 passieren 
wird (kompletter rewrite). Das in die aktuelle Version mit 
reinzufriemeln macht nicht so viel Sinn, da diese Version einfach noch 
nicht auf dieses Maß an Modularität ausgelegt ist.

Kann allerdings zur Zeit nichts darüber sagen, wann ich da die ersten 
Alphas fertig haben werde.

Viele Grüße,
Chris

wir möchten mit eclipse programmieren, compilen und flashen. Kannst du 
uns da eine hilfestellung geben wie man die .bat/mak toolchain 
einbindet? Danke im vorraus :)

Ano Nym schrieb:
> wir möchten mit eclipse programmieren, compilen und flashen. Kannst du
> uns da eine hilfestellung geben wie man die .bat/mak toolchain
> einbindet? Danke im vorraus :)

Prinzipiell ja. Aber was genau ist das für eine Toolchain? :D
Als ersten Anhaltspunkt kannst du dir ja mal die Toolchain-Definition 
von dem Plugin anschauen. Einfach die .jar-Datei mit einem ZIP-Programm 
öffnen und die plugin.xml in einem Texteditor anzeigen. Am Besten nimmst 
du aber erstmal eine ältere (zb 
http://fujitsu.chrilly.net/eclipse/updatesite/plugins/net.chrilly.fujitsu.eclipse_mcu_1.1.2.jar), 
da dort noch nicht 99% der Datei aus Controller-Definitionen bestand ;)

Für weitere Fragen müsste ich dann eben erstmal genauer wissen, worum es 
geht, aber das bitte in dem andren Thread (ich beobachte den) oder 
meinetwegen Mail, hier geht es ja erstmal um die 16bit-Integration bzw 
das Plug-In dazu.

Grüße,
Chris

Email ;)

hey christian, was genau muss ich beachten wenn ich eclipse mit dem 
plugin unter linux verwenden will. woher nimmt dann eclipse die 
toolchain, da es ja keine packages von FME für unix systeme gibt.
danke

Hi,

um unter Linux mit Eclipse für die 16FX-Controller entwickeln zu können 
musst du Softune Compiler+Linker mit Wine installieren. Dann musst du in 
Wine die Registry so bearbeiten, dass der Softune\bin-Ordner im 
Wine-PATH liegt:
1. $ wine regedit
2. zu HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session 
Manager\Environment navigieren
3. Den Wert PATH so anpassen, dass er den Pfad zum Softune\bin-Ordner 
enthält (also zB "C:\Softune\bin;ALTER WERT VON PATH")

Auf dem Host-System musst du noch Wrapper-Skripte anlegen. zB unter 
/usr/local/bin je ein Skript mit den Namen: f2ms, fasm907s, flib907s, 
flnk907s, fcc907s. Jedes Skript muss gemäß dem Namen folgenden Inhalt 
haben (Beispiel für f2ms):
#!/bin/sh
wine f2ms.exe $@

Alle Skripte ausführbar machen (chmod +x).

Desweiteren brauchst du noch make im Hostsystem. Dann sollte eigentlich 
alles laufen. Was nicht geht: Flashen von Linux aus, da Wine virtuelle 
Comports nicht mag. Wenn du über einen echten Comport flashst könnte 
es klappen, kann ich aber nicht testen.
Abhilfe wird ein Linux-lauffähiger Flasher schaffen, der ist aber noch 
in Entwicklung ;)

Grüße,
Chris



Peterle Anonym schrieb:
> hey christian, was genau muss ich beachten wenn ich eclipse mit dem
> plugin unter linux verwenden will. woher nimmt dann eclipse die
> toolchain, da es ja keine packages von FME für unix systeme gibt.
> danke

Hi Sebastian,

danke für das Lob, man freut sich doch immer über Feedback, das erhöht 
auch die Motivation für die Weiterarbeit an V2 ;)

Linkage Order ist im Prinzip schon die richtige Stelle für diesen Zweck, 
allerdings ist diese im aktuellen Plugin mit den Standardeinstellungen 
nicht nutzbar. Das liegt an der Art und Weise, wie Eclipse das Makefile 
aufbaut, welches dann mit make abgearbeitet wird.

Was du machen kannst: Stell in den Project Properties unter "C/C++ 
Build" auf der rechten Seite den "Builder Type" auf "Internal Builder". 
Dann funktioniert die Linkage Order, allerdings arbeitet der Internal 
Builder nach meinen Erfahrungen nicht ganz so sauber wie Make, d.h. du 
musst unter Umständen ab und an mal ein Clean Project ausführen, damit 
er sauber neu kompiliert.
Achtung: Internal Builder geht bei Library-Projekten gar nicht! Dort 
kann man nur mit make (External Builder) arbeiten.

Grüße,
Chris

Hi zusammen,

da ich mich zur Zeit mit der konkreten Planung des Plug-Ins v2, ein 
kompletter Rewrite, beschäftige (zumindest so weit es die Klausurenphase 
in der Uni zu lässt ;) ), würde ich mich über einige Inputs eurerseits 
freuen.

Konkreter wären das die Fragen:
- Wer nutzt das Plug-in bereits in der bestehenden Form (einfach mal aus 
Interesse =) )?
- Wer entwickelt für andere der klassischen Fujitsu-MCU-Familien (also 
alles, was mit Softune-Compilern daher kommt)?

Und das wichtigste:
- Was würdet ihr am liebsten an Erweiterungen/Verbesserungen im 
Gegensatz zum aktuellen Stand sehen? Dabei komplett freie Ideen, was 
realisierbar ist würde ich dann selber schauen ;) Natürlich wird euch 
das Plug-In keinen Kaffee kochen


Größere "Verbesserungen" gegenüber dem aktuellen Stand die bereits fest 
geplant sind, damit klar wird, in welche Richtung das ganze gehen soll:
- Unterstützung aller Softune-Toolchains, also auch 8 und 32 bit.
- Integrierter Flash-Programmer (vorerst steht nur 16FX fest, andere 
Familien würde ich aber nach Möglichkeit ebenfalls gerne abdecken) und 
dadurch Platformunabhängigkeit (sprich Mac OS und Linux, der Compiler 
lässt sich dort ja bereits durch Wine ausführen)
- Bessere Projekteinstellungsverwaltung (zB sollte man nicht in jedem 
Tool (Compiler, Assembler, Linker etc den Mikrocontroller getrennt 
einstellen müssen)
- Nach Möglichkeit Import von Softune-Projekten
- ABS Parser, so dass man leicht den generierten Assembler-Code mit dem 
C-Quellcode und dem zugehörigen Binärcode vergleichen kann
- Geplant ist auch ein integrierter Debugger, wahrscheinlich aber 
ausschließlich für 16FX, da die HW dort bereits das nötige mitbringt


Das war es fürs erste. Ich würde mich über jegliche Rückmeldung freuen. 
Wie bereits oben geschrieben erhöht quasi alles die Motivation bei der 
Weiterentwicklung ;)

Grüße,
Chris

Hallo Chris,

ich bin ein großer Fan dieses Plugins! Ich habe lange mit den Fujitsu's 
beruflich gearbeitet und ich war ziemlich genervt von der 
Softune-Umgebung. Inzwischen bastel ich nur noch privat damit, dann aber 
nur noch mit Eclipse und dem Plugin.

Eine Funktion zum Import von Softune-Projekten wäre wirklich total 
genial!

Eine anderer Punkt ist die Auswahl des Controllers beim Erstellen eines 
Projekts. Die Auswahlliste ist ziemlich lang und unübersichtlich. Da 
wäre es super, wenn man erst die Controller-Serie und dann den 
Controllertyp wählen könnte. Damit wäre das etwas strukturierter.

Bis dann und viel Erfolg!
Thomas

Hi Thomas,

das mit der Auswahlliste stimmt natürlich, ist aber auch bereits auf der 
Featureliste (nur oben nicht erwähnt ;) ). Da die Liste der Controller 
ja eh aus der Softune kommt, werde ich das irgendwie aufsplitten, also 
zumindest nach Familie, eventuell innerhalb der Familie nochmal die 
ersten zwei Ziffern oder so gruppieren (also zB MB96*** als Familie 
auswählen, dann 34* als Serie, dann den 8HSB als Typ).
Muss ich mal schauen, wie das bei den verschiedenen Familien so passt, 
werde aber schon irgendeine sinnvolle Möglichkeit finden.

Vielen Dank für dein Feedback!

Grüße,
Chris


/PS: Achja, unter https://fujitsu.illy.bz/wiki/ habe ich unter anderem 
auch mal eine Liste der geplanten Features angefangen. Dort werde ich 
auch Votes für einzelne Features sammeln, damit ich sehe wie groß die 
Nutzerwünsche für die einzelnen Features sind.

Hi Sven,

> habe gerade 'gevotet'.
Danke =)

> Eine Idee habe ich noch hinzugefügt: Es wäre super, wenn der
> Buildprozess am Ende den Verbrauch des Flash- und RAM-Speichers anzeigt
> (ggf. abhängig der eingestellen Speicherdistribution). Ich hatte
> irgendwann mal ein Perlskript dafür gebastelt, welches derzeit
> allerdings nur für einen Controllertyp funktioniert. Kann ich bei
> Interesse gern zur Verfügung stellen.
Ja, die Idee hatte ich auch schon (zumindest für Flash). Aber wie 
funktioniert das beim RAM? Das ist doch gar nicht zwangsweise zur 
Compilezeit bekannt? Oder meinst du nur dessen statisch belegten Teile, 
wie sie in der Memory Map stehen?

Interessant ist das jedenfalls definitiv, das muss irgendwie mit rein =)

Grüße,
Chris

> Nur die statisch belegten Teile. Das macht bei uns hier schon den
> Großteil aus, dynamische Speicherverwaltung = Fehlanzeige.
> Ggf. noch die Tiefe des Stacks, was aber vermutlich mit etwas Arbeit
> verbunden ist...
Ja, das mit statisch => das meiste dürfte wohl meistens gelten.
Stack wird schon schwieriger, da der ja durch Rekursion leicht mal gegen 
unendlich gehen könnte ;)
Da könnte man wohl höchstens jeden möglichen Einstiegspunkt betrachten 
(sprich Main und jede ISR) und von dort die Ebenen der Aufrufe in den 
Stack-Usage-Files durchgehen und addieren, bei einfacher Annahme einer 
komplett rekursionsfreien Programmierung.

Das Script würde mich durchaus interessieren. Wenn das keine Probleme 
wegen Firmenbesitz oder ähnlichem macht, darfst du es mir gerne mal 
zukommen lassen ;)

Grüße,
Chris

Hi hk,

Jo, das war das was ich meinte mit statische RAM-Anteile sind 
herausfindbar und ROM sowieso ;)
Wobei ich denke ich das bei ROM von Hand mache, dafür aber nach den 
Flash-Sections aufschlüssele.

Danke aber für den Hinweis.

Grüße,
Chris

Hallo Christian,

wir benutzen schon lange verschiedene Fujitsu-Controller (16LX, 16FX).
Auch ich nutze neuerdings Dein Plugin. Bisher habe ich Softune mit 
Notepad++ als externem Editor genutzt, neuerdings haben wir aber 
Projekte, die sich auf mehrere Kollegen und Verzeichnisse verteilen. Da 
fehlt im Notepad++ leider die Möglichkeit über die Verzeichnisse hinweg 
zu greppen und zu sehen was wo wie definiert ist.

Seit heute morgen läuft bei mir alles in Eclipse. Ich hatte Mühe die 
Projekteinstellungen zu übertragen, also ein Konverter von X.prj in 
.cproject wäre echt nützlich.
Ich habe aber auch noch nicht so ganz verstanden, wie Eclipse die zum 
Projekt gehörigen Files verwaltet. Ich habe die Verzeichnisse meiner 
Kollegen mit

  New Folder -> Advanced -> Link to folder in the file system

eingebaut, und dann mit

  "Exclude from build"

alle Files wieder entfernt, die mich nicht interessieren. Das 
funktioniert zwar, geht aber bestimmt auch eleganter.

hk schrieb:
> Der RAM/ROM Verbrauch wird beim MB96F348 angezeigt, wenn man den Haken:
> "Output memory usage information list" setzt unter:

In unserem Projekt ist der Linker (V30L13) leider nicht in der Lage, 
diese Summe (Remainder) vernünftig zu berechnen:

1

...

2

  00FF8746-00FFFE7B 00007736 --------- GAP  <---

3

  00FFFE7C-00FFFFD3 00000158 --------- USED

4

  00FFFFD4-00FFFFDB 00000008 --------- GAP

5

  00FFFFDC-00FFFFDF 00000004 --------- USED

6

  00FFFFE0-00FFFFFF 00000020 --------- FREE

7

8

  ROM -- Total(00080000)  Used(0007FFE0)  Remainder(+00000020)

9

10

  F2MC-16 Family SOFTUNE Linker Symbol List

In der Zeile mit dem Pfeil gibt es eine Lücke (GAP) von über 30 kByte, 
trotzdem sind (Remainder) nur 20 Bytes frei?

Aber es würde wohl zu weit führen, wenn das Plugin auch noch die 
mangelnden Fähigkeiten des Linkes ausbügeln soll..

Ansonsten: tolles Projekt, weiter so!

Viele Grüße

Paul

Hi Paul,

danke für das Lob. Wie bereits glaub ich vorher schon einmal erwähnt 
sollte hier aber ganz deutlich gesagt werden, dass ich nur einen Teil 
zum aktuellen Plug-In beigetragen habe. Die Basis dieser Version 
existierte schon und wurde von mir lediglich etwas erweitert. Erst V2 
wird eine komplett neue Codebasis bekommen ;)

Zu der Verwaltung der Dateien die zum Projekt gehören: Normalerweise 
kenne ich es auch nur so, dass alles, was zum Projekt gehört (mal von 
Static Libraries abgesehen) prinzipiell auch im Projektverzeichnis 
liegt. Und wenn man wirklich mal was außerhalb liegen hat (hab ich auch 
schon mal für ne Library gemacht), dann kommt das eben über die "Virtual 
Link Folders" mit rein. Allerdings hab ich da nie etwas exkludiert, es 
sollte ja eh nur das eingelinkt werden, wo auch Code verwendet wird.

ROM usage: Die werde ich sehr wahrscheinlich schon manuell berechnen, 
das kann ich ja über das ROM-File von Hand recht leicht machen.

Grüße,
Chris

Hi Stefan,

die Linkage Order ist schon der korrekte Punkt. Funktioniert leider 
allerdings auf Grund der Arbeitsweise von Eclipse+Make nicht mit dem GNU 
Make Builder sondern nur mit dem Internal Builder von Eclipse, der 
manchmal etwas Mist baut.

Gleiches Problem und Lösung hier: 
Beitrag "Re: Eclipse Plugin für Fujitsu 16bit µcs"
Und die darauffolgenden zwei Posts.

Grüße,
Chris

Hi Andi,

das Flashen des Controllers funktioniert nicht über den Button, das war 
zwar angedacht macht aber im aktuellen Aufbau des Plug-Ins keinen Sinn 
einzupflegen. Das kommt erst mit V2.

Aktuell kann also das Flashen nur über den Build-Process erfolgen. Dazu 
muss einerseits natürlich in den Project Settings unter 
C/C++-Build->Settings der Schritt FLASHly aktiviert sein und außerdem 
auch FLASHly an einem Ort liegen, der in der PATH-Umgebungsvariable von 
Windows eingetragen ist.
Um letzteres zu testen kannst du einfach mal in Windows eine Konsole 
öffnen (Start->Ausführen oder Tastenkombination Win+R, dort "cmd" 
eingeben und starten), und dort dann "flashly" eingeben und mit ENTER 
bestätigen. Dann sollte sich der Hilfe-Dialog von FLASHly öffnen, der 
einem die Aufrufparameter zeigt. Wenn dies nicht kommt, sondern die 
Meldung, dass das Programm nicht gefunden wurde, dann ist hier schon der 
Fehler.

Dies ist aber beides auch in Eclipse im Build-Process selber 
ersichtlich. Wenn man dort im unteren Pane auf die View "Console" 
wechselt zeigt er dort jeden Programmaufruf im Build-Process an, am 
Schluss sollte dort der Aufruf von FLASHly stehen und auch, ob er das 
Programm nicht finden konnte.
Die letzten Zeilen bei mir, wenn FLASHly nicht gefunden wurde, sehen zB 
so aus:

1

Upload programm to device

2

flashly -cpu MB96F348HSB -c:0 -Q:4 -E:DF0000 -E:FE0000 -E:FF0000 -nolog -newlog -msgok -P:FW-Motion.mhx

3

make: flashly: Command not found

4

make: *** [flashlydummy] Error 127

5

make: Target `all' not remade because of errors.

Die ersten beiden Zeilen müssen aber immer da sein, sonst ist in Eclipse 
schon was falsch eingestellt und er versucht gar nicht FLASHly 
aufzurufen.

Vielleicht hilft dir das ja schon weiter, wenn nicht melde dich nochmal 
hier ;)

Grüße,
Chris

PS: Welchen Controller verwendest du denn eigentlich?

Hi zusammen,

hab heute Version 1.1.8 vom Plug-In hochgeladen. Neuerung sind hier nur 
ein Update auf die aktuellste MCU-CSV von Fujitsu, d.h. auch die neueren 
Modelle sind nun unterstützt.

Außerdem habe ich ein Setup erstellt, welches einem die ganze 
Einrichtung von Eclipse mit dem nötigen Zubehör abnimmt. Dieses könnt 
ihr unter 
https://fujitsu-eclipse.net/wiki/Old_Page#Prepackaged_Eclipse-Distribution 
finden.

Grüße,
Chris

Hallo Leute,

das ist zwar mehr eine Eclipse-Frage als eine fürs Plugin, aber 
vielleicht könnt Ihr mir trotzdem weiterhelfen:

Ich hatte bisher ein Makro

1

#define EMULATOR

welches ich immer nach Bedarf auskommentiert hatte. Diese Makro schaltet 
im Startupcode das Background-Debugging aus oder ein, und im restlichen 
Programm Testausgaben usw.

Nun bin ich auf die Idee gekommen, ein Debug- und ein Release-Target in 
Eclipse anzulegen. In den Projekeinstellungen des Plugins habe ich dann

1

EMULATOR

unter Define Macro eingetragen - einmal beim Assembler, einnal beim 
Compiler.
Das funktioniert so weit ganz gut, aber der Editor weiss jetzt nicht 
mehr, dass

1

EMULATOR

definiert ist, faltet deshalb die Zeilen zu und findet sie auch nicht 
bei C/C++ Search.

Was kann ich tun? Gibt es irgendwo eine Projekteigenschaft, auf die auch 
der Editor zugreift?

Paul

Hi Paul,

das war mir auch schon mal aufgefallen, habe mich aber nicht weiter um 
die Suche einer Lösung gefunden. Wenn das also jemand weis wäre ich auch 
erfreut es zu erfahren ;)



@All:
Habe mal auf Grund einer Anfrage ein kleines Programm geschrieben, 
welches einem eine Call Hierarchy eines Projektes aufbaut und anzeigt, 
und dabei auch anzeigt, welche Methode wieviel Stack benötigt bzw. 
wieviel Stack inklusive aller aufgerufenen Methoden. Weitere Infos 
unter: https://fujitsu-eclipse.net/wiki/CallHierarchyAnalyzer

Grüße,
Chris

Hallo Christian,

ich habe heute mal den CallHierarchyAnalyzer ausprobiert. Allerdings 
zeigt der bei mir nichts an. Wenn ich ihn starte (Kommandozeile und auch 
"select folder" ausprobiert), macht er für 7 Minuten (!) ca. 12% 
Systemlast, hört dann auf und zeigt nichts.
Liegt das vielleicht an meinem Win7 X64?
Ich benutze ein JRE-6u26.
Probiert habe zwei Projekte, die auch wirklich .stk Files enthalten, bei 
Softune in \obj, bei Eclipse im \Release

Woran liegt's? Ist mein neuer PC zu langsam... (core i7)?

Paul

P.S.: hat nicht schon jemand einen Vorschlag, wie der Eclipse-Editor 
#defines aus den Projekeigenschaften berücksichtigt?

Hi Paul,

das ist merkwürdig. Eigentlich sollte das recht flott gehen. Bei meinem 
Beispielprojekt dazu (liegt im SVN - 
https://svn.fujitsu-eclipse.net/CallHierarchyAnalyzer/demo_project/Release/, 
Nutzer "gast") dauert es bei mir ca. 3 Sekunden. Die CPU etc dürfte da 
auch keine wirkliche Rolle spielen ;)
Bekannte an der Uni haben das auch mal ausprobiert und da lief es wohl 
auch.

Wäre es möglich, dass du mir mal die .stk-Dateien zuschickst?

Grüße,
Chris

Hallo Christian,

mit Deinen .stk Files klappt es bei mir auch.
Meine Files habe ich dir gemailt.

Gruß

Paul

Hi,

also prinzipiell funktioniert das Programm wohl, auch mit den Daten von 
Paul. Allerdings ist wohl die JTree-Komponente aus dem Swing-Framework 
nicht fähig, mehr als ~1000 Knoten gescheit zu verwalten. Werde ein 
bisschen rumbasteln und vielleicht heute Abend eine neue Version 
rausbringen, die besser läuft.

Grüße,
Chris

Hi,

hab nun mal Version 2 Hochgeladen. Das Bild im Wiki passt erstmal nicht, 
ne genauere Beschreibung will ich später dann auch noch dort erstellen.

Fürs erste sei gesagt, dass Version 2 wesentlich schneller arbeitet 
(wobei es bei gewissen Projektgrößen in der Gesamtansicht extrem 
unübersichtlich wird ;) ). Außerdem wird das ganze nun richtig als Baum 
gerendert.

- Im Baum Werden die Methoden, welche den meisten Stack brauchen 
(bezogen auf jeweils alle Methoden, die von der gleichen "Elternmethode" 
aufgerufen werden) in rot gezeigt, alle anderen grün.
- Linksklick auf ein Element im Baum: In einer Tabelle werden dessen 
Eigenschaften gezeigt.
- Durch einen Doppelklick auf eine Methode wird der Teilbaum 
zusammengefaltet. Durch einen weiteren wieder auseinander.
- Mit dem Scrollrad der Maus kann man den Baum zoomen
- Mit Maus gedrückt halten kann man den Baum verschieben (bzw. die 
Ansicht darauf)
- Später will ich noch die Möglichkeit schaffen, per Rechtsklick einen 
beliebigen Teilbaum in einem neuen Fenster zu öffnen.

Soweit erstmal. Feedback ist sehr willkommen ;)

Grüße,
Chris

Version 2.1 hochgeladen, Wiki-Beschreibung aktualisiert und ergänzt. Ist 
für mich, solange keine Anregungen/Bugs eintrudeln, erstmal final.

Grüße,
Chris

Hallo Christian,

hast Du schön gemacht, hier funktioniert das jetzt auch prima!

Paul

Hi Andy,

Indigo habe ich leider selber noch nicht in Verwendung, außer in einem 
Paket, wo ich das Plug-In schon mitliefere über die dropins. Aber 
zumindest bis Galileo landeten über P2 installierte Plug-Ins (also auch 
über die Oberfläche) zum einen im Ordner "/features" als Unterordner, 
und außerdem eine JAR-Datei im Ordner "/plugins". Denke das sollte 
auch bei Indigo noch gleich sein ;)

Zu dem Headless-Build kann ich leider gar nichts sagen, damit habe ich 
mich bisher noch nie beschäftigt, wobei das so aussieht, als ob er im 
Headless-Mode Probleme hätte die richtigen Einträge vom Plug-In zu 
laden. Kannst du das Projekt problemlos in der Oberfläche laden, die 
Toolchain-spezifischen Einstellungsdialoge benutzen und kompilieren?

Wozu wird der Headless-Build genutzt? Wäre es eventuell generell eine 
Alternative direkt die makefiles zu starten? Spart auch den Overhead der 
Eclipse-Runtime ;)

Grüße,
Chris

> Genau so sieht es bei mir in Galileo auch aus. Bei Indigo ist es mir ein
> Rätsel wo das Plugin installiert wurde. Finde überhaupt nichts was mit
> Fujitsu oder net.chrilly zu tun hat.
Hast du auch schon mal in deinem Nutzerprofil geschaut? Also 
C:\Users\{name}\Anwendungsdaten\.eclipse oder sowas vielleicht? Könnte 
mir vorstellen, dass die bei Eclipse mittlerweile auch mitbekommen 
haben, das Programmverzeichnisse für Einstellungsdaten nicht taugen ;)

> Ich kann das Projekt über die Oberfläche laden, mit deinem Plugin
> konfigurieren und auch das Bilden mit Softune funktioniert mit dem
> Plugin wunderbar.
Das ist dann echt merkwürdig. In Bezug auf den vorigen Punkt: Wird 
Eclipse beim Headless-Modus unter dem gleichen Benutzer aufgerufen? Muss 
eventuell ein Workspace mit angegeben werden oder sowas?

> Habe das Projekt nicht mit Make aufgebaut weil das Managed Builden mit
> CDT zu meinem Erstaunen bestens funktioniert hat. headlessbuild, um das
> ganze Projekt (da sind noch weitere Tools im Spiel) mit Skripts zu
> bilden. Ist mir klar, dass es mit Make eleganter wäre, aber das ganze
> hat bei Galileo tiptop funktioniert.
Managed Build hat ja erstmal nichts damit zu tun, ob es mit Make läuft. 
Eclipse's Managed Build unterstützt zum "Builden" verschiedene Systeme, 
darunter einen internen Builder (und der hat bei mir zumindest früher 
öfter mal Probleme bereitet) und eben Make. Von der Nutzung her in 
Eclipse sieht beides identisch aus, nur wird bei dem Weg über Make 
automatisch ein makefile generiert und mit Make ausgewertet. Dieses 
Makefile kann man dann aber auch ganz normal auf der Konsole nutzen 
(wobei die Pfade zu den Programmen natürlich in der Umgebungsvariable 
"PATH" stehen müssen). Das beinhaltet aber natürlich nur den Anteil des 
Builds, der zum Plug-In gehört, keine external Tools oder derartiges was 
man vielleicht noch in Eclipse eingestellt hat.
Die Unterscheidung Internal Builder vs Make sieht man in den Project 
Properties unter "C/C++-Build" direkt im Tab "Builder Settings". Da 
steht "Builder Type" entweder auf "Internal Builder" oder "External 
Builder" (-> Make)


> Denkst du ich kann die von Eclipse automatisch generierten Makefiles
> nutzen? Oder wäre es dann nötig eigene zu schreiben und ganz auf den
> Managed Build verzichten?
Wie gesagt, zumindest normalerweise sind die Makefiles die Eclipse 
generiert ohne weiteres auch getrennt nutzbar ;)


Grüße,
Chris

> Um was für Einträge handelt es sich dabei? Wo sind diese gespeichert?
> Viellicht könnte ich da etwas vergleichen mit meiner alten Installation.
In der JAR-Datei des Plug-Ins gibt es eine plugin.xml, dort sollten 
diese Schlüssel 
(org.eclipse.cdt.fujitsuF2MC16.exe.target.win32.MB96F326RSA.release) 
drinstehen. Das ist die Toolchain-Konfiguration für die jeweilige CPU.

Hallo,

ich bin auf der Suche nach einem Plugin für die Fujtsu FR60 MB91460B 
Serie.

Hat jemand so etwas?

Gruß
Jackson