Für lange Winterabende....

[oderlachs]

Hallo W_F !

Natürlich gibt es auch graue Herbsttage, aber ich persönlcih habe da noch Dinge von der "Sommerpause" aufzuarbeiten, soweit man das Hobby als "Arbeit" bezeichnen darf..

Hätten wir noch richtigen Winter, ginge es tagsüber hinaus in die Weisse Natur und abends ermüdet ins Bett, aber ein richtiger Winter ist ja auch schon ne Rarität...

Ich habe mich also erst mal mit Keil AVR/ARM/51 ausgestattet, natürlich die Freeware mit ein paar KB für die Code...die kaufversion steht zu keiner Realität der Verwendung bei mir.
Em::Blocks habe ich auch , sehe da nun gar nicht durch...noch nicht...und CoCox weiss ich nicht, muss mich da erst Registrieren...

Mir persönlich wäre KeilARM angenehme, da ich dort schon in der 51er Version (8051) ein bischen gearbeitet habe...

Na ja , die hauptsache ist das man was draus machen kann aus dem Board, wie das ist dann noch offen für mich, nur sollte es "Zeh" sein, ASM habe ich fast seit der C64' er Hoch-Zeit nicht mehr "gehämmert"...
Aber es hat Spass gemacht für Geos-Anwendungen Grafik/Icons Bittweise zu "zeichnen" ...nee tippen.

Gerhard

[White_Fox]

Ich finde ja, ASM muß jeder mal programmiert haben der programmieren lernen will. Aber für ARMs würde ich mir das auch nicht antun wollen, wenn man das auf einem 8-Bit-Käfer kann reicht das. Ich würde auch C vorschlagen. Muß mich da auch erst wieder etwas reinarbeiten, habe C bisher nur unter Windows angewendet und muß erstmal sehen was bei Mikrocontrollern dann alles anders ist.

Aber noch was zur IDE: Dann würde ich doch lieber vorschlagen, als Konsens dieses EM-Dingens zu verwenden. Keil ist mir aus zwei Gründen unsymphatisch: Einmal entweder Beschränkung oder Kauf, wobei ich das Geld auch nicht ausgeben kann und würde, also bleibt auch mir nur, mit der Beschränkung zu leben. Wobei ich das nicht einsehe, da es wirklich gute Open-Source- bzw. Freeware-IDEs gibt (Netbeans, Eclipse, EM-Dingens).
Zweitens habe ich mir (u.a. von einem Prof an meienr Uni) sagen lassen, das Keil im Vergleich mit anderen IDEs auch nicht so der Bringer ist. Warum also mit Beschränkung leben?

Außerdem habe ich noch die Möglichkeit, Visual Studio vollständig zu nutzen, instaliert habe ich es auch noch. (Student sein hat seine Vorteile. ) Eine weitere IDE kann ich von daher auch nicht wirklich gebrauchen.

Da das Tut nunmal mit EM-hastenichjesehn arbeitet wäre es insofern ganz sinnvoll damit anzufangen, da das in dem Tut auch ganz gut erklärt zu sein scheint. Wenn wir sicher genug sind kann ja jeder zu seiner Lieblings-IDE umsteigen.

[oderlachs]

Nun ja ich will mich an Keil nicht festhalten, aber für meine kleinen AT89x5x Versuche war das bestens, zumal es da kaum auf Codegrösse ankam zum lernen und Verstehen, ich hatte/Habe da ein MCU-8051 zu liegen und 2..3 Chips die ich mal testen wollte, das ging für mich da mit Keil am besten...
Ich denk aber wenn mein "Brett vorm Kopp" bei EM::Blocks entfernt ist komme ich damit auch klar und man kann /möchte ja lernen....Nein es ist heute als Hobbyprogger nicht mehr nötig sonst was für Software auszugeben, weil es genügend FreeCode gibt.
Wenn ich da noch an meine Taschengeldverlust zu Zeiten von Delphi1,2,3 usw.. denke , so schnell konnte keiner Sparen..

Gerhard

[PICture]

Hallo!

Ich finde ja, ASM muß jeder mal programmiert haben der programmieren lernen will.

Ich bin gleicher Meinung !

Aber nur solche davon, für die "Hex" schon wie "Dec" ist. Ich habe früher PC CPU's (von 80186 bis Pentium) umfangreich in ASM programmiert. Deshalb denke ich, dass "Umstieg" von 8-bittigen µC's auf z.B. 32-bittige CPU's etwas schweriger wäre.

[oderlachs]

Gewiss , gewiss..schon alleine der ASM Befehlsvorrat dürfte schon "etwas" umfangreicher sein...

Ich bin gerade dabei meinem Board ein wenig Linux , oder besser Linux die Verbindung mit dem STM32 beizubringen. da muss ich erst mal im Web recherchieren..
Na vielleicht hat wer ' ne Hilfestellung für mich in Sachen Linux? Da bin ich ja nun schon zig Jahre so "aktiv" raus...

Gerhard

[White_Fox]

Ist bei den ARMs eigentlich schon Division und Fließkomma-Arythmetik-Unterstützung mit eingebaut, oder erwarte ich da zuviel von den Prozessörchen?

[Wsk8]

Ist bei den ARMs eigentlich schon Division und Fließkomma-Arythmetik-Unterstützung mit eingebaut, oder erwarte ich da zuviel von den Prozessörchen?

Div/Mult ist normal hardwareseitig unterstützt. FPU gibts nur ab Cortex M4.

mfg

- - - Aktualisiert - - -

Zur Vorgehensweise:
- Ihr braucht Emblocks.
- STLink Utility
- Standard Peripheral Library für eure Prozessorserie für die Beispiel. (F0, F1, ...)

Beide Programme installieren.

In Emblocks dann hier noch ein Tool zum flashen der Hex einrichten. (Debuggen funktioniert auch ohne, aber man will ja irgendwann mal ohne Debugger starten )
http://www.emblocks.org/wiki/tutorials/f401_f429_disco/release_target#add_load_hex_tool
Hier müsst ihr normal nur diesen 1 Schritt machen.

Das Tutorial auf Microcontroller.net find ich jetzt teils nicht ganz so toll, da ziemlich viel unnötiges aufgeführt ist.

Im Prinzip müsst ihr bei dem Project Wizard nur euren Prozessor einstellen (in dem Tut gut erklärt) und den Hacken bei "Enable Semihosting" setzen. Sonst würde ich da gar nichts ändern.
Schon könnt ihr euer erstes Programm schreiben und den Debugger starten. Da ist wirklich nichts dabei.

mfg

[oberallgeier]

Div/Mult ist normal hardwareseitig unterstützt. FPU gibts nur ab Cortex M4 ...

Musik in meinen Ohren. Denn bei mir liegt ist das STM32F4DISCOVERY Board, da steht in der Kurzbeschreibung "... STM32F407VGT6 microcontroller featuring 32-bit ARM Cortex-M4F core, 1 MB Flash, 192 KB RAM in an LQFP100 package ...". Und ich hoffe, dass das "F" im M4F kein Downsizing-Zusatz ist. Da sehe ich fast schon, dass ich (wieder mal) Rechenzeiten von transzendenten Funktionen messen werde.

Das Board hatte ich ja zur Seite gelegt . . . weil . . . aber Deine Rede macht ja wirklich Mut. Ich hoffe nur, dass ich nicht übermütig werde und mich überstürzt da reinhänge. Denn - erst ist noch mein Archie dran, der soll auf einen halbwegs passablen Zustand gebracht werden. Übrigens hatte ich genau dieses Disco-Board eigentlich für das Projekt Archie gekauft und bin dann eben auf die mir halbwegs bekannten 8Bitter von Atmel als I²C-UART-Teamworker ausgewichen. Vor allem - weil ich von mehreren Seiten vor der Komplexität der ARMs gewarnt wurde.

[oberallgeier]

... Zur Vorgehensweise:
- Ihr braucht Emblocks.
- STLink Utility
- Standard Peripheral Library für eure Prozessorserie für die Beispiel. (F0, F1, ...)
...
In Emblocks dann hier noch ein Tool zum flashen der Hex einrichten ...

Das ist ja schon fast ein Tutorial, danke. Nun habe ich mal eine Frage/Bitte: Üblicherweise sichere ich bei Platinen mit aufgespielten Demos die Firmware (hex, EEPROM, Fuses, etc) - damit ich mal später, wenn mal wieder etwas nicht läuft, nachsehen kann ob wenigstens die Demo unverändert läuft. Deswegen würde ich die Demo erstmal sichern - und das ohne jegliche Ahnung wie ich das machen soll.

Daher meine Bitte um eine Liste der Arbeiten - wirklich für Dummies - mit denen ALLE Modifikationen auf meinem STM32F4DISCOVERY Board gesichert werden (können). Danke im Voraus.