|
Anzeige
|
stm32 tutorial
Gast
#2232317
Hallo, hat jemand zufällig einen Link zu einem brauchbaren Tutorial zum erstellen eines Projektes mit einem stm32F107. Also wie genau die Bibliotheken einzubinden sind und welche, scheinbar macht das jeder anders und seit 107 sowieso im Vergleich zum 103. Momentan blick ich überhaupt nicht durch wofür was steht. Moin Paul, 107 vs. 103 sind nur verschiedene Perepherie aus stattungen für ein und den selben Prozi: Cortex M3. F103 Performace line, f107 Connectivity line(Lan, USB host) usw. Zum Tutorial, es gibt ein Tut fürs STM32Discovery Board, aber für welche IDE willst du ein Tutrial? Sonst schau mal bei CooCox.org ich bin da auch erst vor kurzem drauf gestoßen sicht ganz gut aus für Anfänger in der Richtung, Ich probiere es selbst gerade aus. Hast du mal im STM32 Artikel hier geschaut da steht auch sehr viel, es gibt dort auch schon einen Artikel wie du Eclipse dazu überedest mit dem STM32 zu arbeiten. MfG Tec
Gast
#2232405
Ich hatte die Vision das auf dem Atollic Studio laufen zu lassen und auf Keil und dachte es wäre vielleicht möglich zumindest für den Anfang zwischen beiden zu wechseln, da man mit Keil gut simulieren kann. Was denkst du, kann Coocox dem Atollic das Wasser reichen? Ich meinte mit dem Unterschied der 103 und 107, dass sich scheinbar die Namen der Bibliotheken die man einzubinden hat geändert haben, da ich eigentlich anhand alter Projekte ersehen wollte wie das alles genau einzubinden ist. Ich habe inzwischen das Tutorial für das Attolic gefunden und wollte halt versuchen es auch mal unter Keil laufen zu lassen. Sind die C Codes unterschiedlich oder reicht es einfach die GPIO Lib einzubinden? Das Conf-file wird scheinbar von jeder IDE selbst erzeugt, ich dachte am Anfang man müsste die auch einbinden oder schreiben. Sry für die blöden Fragen. Ich hatte bisher das Bild, dass ich einfach nur folgendes Einbinden müsste: #include "stm32f10x.h" #include "stm32f10x_gpio.h" Mainprogramm und die eingebundenen Datein natürlich noch in das entsprechende Verzeichnis kopieren. Und bei kein noch die stm32f10x.h bearbeiten bzw. das #define STM32F10X_CL frei geben.
Gast
#2232496
Das Bild AI15993 erklärt so manches, leider kann ich das zugehörige Dokument nicht finden, aus welchem stammt das, im RM0008 habe ich es nicht (oder über-) sehen. Moin, Was ich bei Coocox gut finde ist das Repostory damit kannst du die Perepherieteile an wählen die du verwendes willst und die IDE bindet die Dateien aus dem stdperphlib von ST ein., Wenn du einen ST-Link hast ist das Atollic wohl die erste Wahl, ich hab n J-Link Edu, und der wird neuer dings von Coocox unterstützt. ich habe bisher mit Eclipse und Codesourcery gearbeitet. Zu den Libs steuerst du das nur über das define STM32F10X_XL_CL müsste f107 weiß ich aber gerade nicht. ich habe bisher nur f103 verwendet. MfG Tec
Gast
#2232533
Für mich sind beide verfügbar, somit ist es egal, ich dachte nur bis jetzt, dass Atollic die bessere Umgebung bildet. Ich versuch mich nachher mal an Coocox. Dieses CooCox sieht echt mal ziemlich gut aus. Muss ich heute abend gleich mal ausprobieren! :)
Gast
#2234983
Also ich habe jetzt mal Keil, Atollic und Coocox ausprobiert. Coocox bietet auf jeden Fall erst mal einen schönne Einstieg, dort sieht man was benötigt wird. Verwirrend fand ich nur, dass scheinbar alle Editoren unterschiedliche Initialisierungen verwenden Atollic das SystemInit, Keil das stm32_Init ect. und das Coocox extrem viele Datein einbindet. Außerdem verwirrt mich das SMSIS noch etwas, soweit ich das verstanden habe nutzt man das erst bei komplizierteren Funktionen um Einheitlich zu bleiben bzw. nicht jedes mal alles neu erfinden zu müssen (Filter ect.) und nicht bei einfachen Ein und Ausgabe Funktionen. Ich habe die Programme mal nach Keil geschoben, da der einen Simulator bietet, was die anderen scheinbar nicht können. Die Codes scheinen sonst also leicht austauschbar zu sein. Tja sonst scheint mir Atollic etwas Aufwendiger (viele kleine schöne Funktionen) und Coocox ist mir etwas suspekt, weil ich noch nie was davon gehört habe^^ (dummer Grund ich weiß). Anderer seits ist es gerade wegen seiner Einfachheit genial und ein dicker Plusspunkt natürlich dafür, dass es frei und fertig ist und sogar den Jtag von NGX zu unterstützen scheint. Wäre schön wenn einer was dazu sagen könnte der Ahnung hat ;-P Nunja, hätte ich das eher gewusst hätte ich mir gleich mal das Coocox angeguckt, dann Atollic und Keil und dann erst versucht mit Yargatho zu zaubern.
Gast
#2235025
oh und was zum Geier ist diese stm32f10x_lib.h Datei, ich finde nichts was so aussieht in den Demo Projekten und wenn ich die in ein neues Projekt einbinden wollte, dann wird sie auch nicht gefunden. Moin CMSIS ist ein Bibliotheksstandard von ARM, Die nicht nur für komplizierte Sachen ist, sonder auch für simples IO switchen. Jeder Herrsteller wie z.b. ST, erweitert das Lib mit den Perepherie Funktionen. So hast du eine einheitliche APi für alle Cortex M3 so der Plan. Funktiononiert auch ganz gut so weit ich das zwischen TI und ST vergleichend sagen kann. Ein Projekt mit der Lib zu bauen ist nicht so einfach, am besten schaust du in die ST lib rein dort gibt es Templates also leere fertige Beispielprojekte für Keil usw. Attolic sollte das ST lib standardmäßig benutzen meine ich. Für Keil kopierste dir das Template und gut ist. Auf die Ordnerstruktur dabei achten. Bei Coocox, klickste die Komponenten an und er haut sie in dein Projekt das du sie verwenden kannst. Für den Anfang finde ich die Libs sehr sinnvoll. Wenn mal was zu langsam ist mit Lib, dann kannste das ohne Lib schreiben. Aber sonst würde ichs Lib nehmen, alleine schon wenn du vllt mal von einem STM um anderen Wechselst kannste den Code fast 1:1 übernehmen. MfG Tec
Gast
#2235109
einige Fragen: - Wie sieht es mit der C++ Unterstützung von Coocox und Attolic aus ? - Kann man printf, sprintf dort "out of the box" mit vergleichbarem Speicherverbrauch wie bei Keil verwenden ?
Gast
#2235278
Aus der Lizenz werde ich nicht ganz schlau, kann man das CMSIS jetzt benutzen wie man möchte oder gibt es Einschränkungen? Moin, Das mit dem printf in Keil müsste über den Override der putc Funktion durch die CMSIS Funktionen ITMSendChar laufen, ITM unterstützt Coocox leider noch nicht. Was Cpp angeht kann ich nix dazu sagen hab bisher nur C genutzt. Ich sage mal so gegen über einer ide wie Keil bietet Coocox nur, den Eclipse eingabe stil mit der Codecompletition usw. und die Möglichkeit sich seine Projekte zusammen zu klicken. Sons ist Keil und IAR wesendlich mächtiger. MfG Tec Moin, ich habe gerade bei mir noch n Dokument zu CMSIS gefunden, für interessierte was Arm sich dabei gedacht hat. MfG Tec
Gast
#2235502
Das Tutorial gibt es auf: http://www.doulos.com/knowhow/arm/CMSIS/CMSIS_Doulos_Tutorial.pdf Wahrscheinlich liegt es an meinen schlechten Englischkenntnissen, aber so 100% verstehe ich noch nicht wie ich jetzt damit umgehen soll. Mir erschließt sich nur, dass es mir bei der Initialisierung hilft und Funktionen neu (einheitlich) benennt. Einfache Beispiele dazu konnte ich aber noch nicht finden, vielleicht habt ihr ein paar gute zum STM32f107 ? Die ST Lib hält sich an diese Konventionen in der Lib findest du Beispiele zur Lib, und das BSP zum Systick ist z.b. nur rein CMSIS funktionalität weil das nur der Kern macht und keine Perepherie braucht, gut glaube ein GPIO für ne LED wird da glaube ich benutzt. Die anderen Fkts der ST Lib sind St eigen halten sich aber an CMSIS (CMSIS complaint) -> Benutzt du das ST lib , benutzt du indirekt CMSIS mit. MfG Tec Stell Dir vor, der Chip besteht aus zwei Teilen: 1) Einen Teil, der die Grundfunktion der CPU gewährleistet, also Speicher-Bereiche definiert, einen Timer, einige Interrupts zur Verwaltung u.s.w. Auch die Position der Interrupt-Adressen, Start-Adresse (Reset) und Initialwert für den Stackpointer sind dort definiert. 2) Einen weiteren Teil, den der Hersteller mit beliebig viel RAM, FLASH, GPIOS, ADC, SPI, USART, I2C.... voll stopft. Der Teil 1) ist bei allen CortexM (oder sogar allen Cortex?) gleich, weil er von ARM fest gelegt ist und in der vom Hersteller gekauften/lizensierten IP schon drin steckt. Der Teil 2) ist das was der Hersteller zum Chip dazu tut. Die CMSIS nutzt Du schon, wenn Du nur den Reset ausführst. Der Vorteil ist, dass Du also ein System programmieren kannst, dass auf allen CortexM3 verschiedener Hersteller ohne all zu große Änderungen schon mal bootet. Innerhalb der STM32 Familie habe ich das schon sehr genossen, da STM das ganze noch weiter ausgefeilt hat. Hier ist nämlich auch der Teil 2) in ein paar Gruppen unterteilt und nur durch einbinden der stm32f10x.h kann man mit ein wenig Geschick eine Software programmieren, die auf allen STM32F10x lauffähig ist, man muss ggf. nur zwei #defines ändern oder als parameter beim make übergeben. Wenn Du ohne weiteren Tiefgang mit einer der (teil-)kommerziellen IDEs arbeitest, wirst Du das nicht zu schätzen wissen, aber wenn Du mal ein OS für eine CPU portiert hast, dann wirst Du das lieben :) Auch wenn dann nur die stm32f10x.h übrig geblieben ist... Bin gespannt, wie sich die stm32f20x.h so macht. Gruß, Ulrich
Gast
#2235917
Danke, noch eine blöde Frage, wo bekommt man die Befehlsübersicht her mit der man das Teil programmiert. Ich habe mal die Datenblätter nach ein paar Befehlen abgesucht und nichts gefunden. Stehen die in den IDE Hilfen? Ich meine irgendwo muss doch stehen wie man z.B. die Pins setzt. Bzw. irgendwie muss ja mal einer angefangen haben. Das RM0008 ist gute nachtlektüre für dich und sonst die Doku zu dem ST stdperphlib. wenn du das Library von St geladen hast dann ist dort die Doku mit drin in dem Paket, als eine chm datei. MfG Tec Du willst doch ein OS nutzen. Dann schau Dir darin die vorhandenen Samples an. So habe ich vor längerer Zeit den Einstieg ins Nut/OS gefunden. Einfach mal aus den Beispielen eines für GPIO, eines für UART und eines für HTTP compiliert, gestartet und dann per Code scrollen nachvollzogen, was da passiert. Dann aus den verschiedenen Beispielen den ersten eigenen Code zusammen gestöpselt. Und da es zwischendurch immer wieder funktioniert hat, macht es auch Spaß. So viel, dass zuerst ein paar neue Treiber hab, die ich beigesteuert habe und zuletzt habe ich den CortexM3 portiert. So kanns gehen. Bei einem gut gemachten OS wird sicherlich nicht unbedingt die lib von ST angezogen und weiter verwendet. Denn diese ist zwar sehr instruktiv, wenn man ohne OS selber Code auf die Beine stellen möchte, aber sie ist ineffektiv, was ihre Performance angeht. Ein gutes OS, welches außerdem verschiedene Architekturen oder CPUs unterstützt, zwingt den Programmierer nicht dazu, für jede unterstützte Platform eigene Befehle für ein und die selbe Sache zu lernen. Also wenn ich einen AVR mit diesem OS verwende schreibe ich GPIOB = 0x23, wenn ich einen SAM7 verwende, muss ich GPIOB.BRR=0xff und bei einem Cortex schreibe ich dann GPIOB->BSRR=0xab.... Scherz! Nein: Darum kümmere ich mich nicht, sondern schreibe immer GpioPortSet(GPIOB, 0x23) und hoffe, dass der, der das portiert hat, sich große Mühe gegeben hat das schnell und effektiv zu erledigen. Wenn ich das dann verinnerlicht habe, nutze ich das OS für alle meine CPUs. Bei FreeRTOS und anderen ist das so und auch bei Nut/OS ist das so. Dass CooCox die STM libs anzieht stimmt mich nachdenklich... habe es aber noch nicht genauer untersucht. Ich verwende Nut/OS und mache damit private Basteleien und kommerzielle industrielle Produkte gleichermaßen. Egal ob auf AVR, ARM oder Cortex. Du wirst Dir auch dein Lieblings/OS aussuchen und es nicht mehr wechseln, wenn es nicht sein muss. Gruß, Ulrich
Gast
#2236780
Also an in OS wollte ich mich eigentlich nicht gleich heran wagen und ich dachte nicht, dass CMSIS schon an ein OS bindet. Welches verwendest du, bis jetzt habe ich nur von FREERTOS gehört als freie Version. Vielleicht hast du mal einen Link der das gut beschreibt bzw. ein Demoprojekt spendiert. Bis jetzt hatte ich eigentlich vor mit der ST Lib zu schreiben, da ich eigentlich nur ein paar IOs Ein und ausgeben muss + Interrupts, etwas am CAN spielen und ein paar DAC und ADCs verwenden wollte. Zusätzlich zu ein paar Berechnungen. Und das mit dem Atollic Studio (sehr wahrscheinlich). Danke für den Tipp mit der ST Lib das Verzeichnis ist bei mir hinten runter gerutscht, weil die bei Atollic schon eingebaut waren ;-P. Ich versuche jetzt erst mal die ADC zu laufen zu bringen.
Gast
#2236925
Eigentlich hatte ich bisher gedacht, dass CMSIS die Funktion erfüllt die jetzt das OS verspricht nämlich ein einheitliches Programmieren auf verschiedenen Architekturen und das leichter initialisieren. FreeRTOS klingt schon interessant, aber scheint noch nicht ganz ausgereift und ich muss irgendwie mal zu Potte kommen. Ich denke ich werde mich an den von allen hier verfluchten ST-Libs versuchen (vorerst). Hi Paul, Das CMSIS stellt vereinheitlichte Werkzeuge für ein OS zur Verfügung, es ist nicht selbst ein OS. Beispiel SysTick Timer. Bisher musste man immer irgend einen, bei jeder Architektur anderen, Timer zweckentfremden um eine Referenz-Clock für einen Task-Switcher im OS zu haben. Oft ist es aber so, dass bestimmte Timer in einem Chip mit bestimmten anderen Funktionsblöcken gekoppelt sind. Man verlor also nicht nur einen Timer, sondern auch noch ein paar Zusatzfunktionen. Oder man hat den Timer mit den wenigsten Zusatzfunktionen gewählt, der aber eventuell auch nur sehr klein war, also musste man im SysTick-Interrupt zum einen sehr weit herunter teilen, was zusätzliche Zyklen verbraucht und man hat sehr viele Interrupts/s. Das CMSIS definiert nun einen Timer, der ausschließlich für die Aufgabe da ist einen Takt von z.B. 1ms zu erzeugen und nix anderes. Außerdem muss ein OS eine Menge Verwaltung erledigen, bevor es einen Task abbricht und auf einen anderen Task wechselt. Auch das ist in der Cortex Architektur verbessert, denn der SysTick-Interrupt kann automatisch den Prozessor in einen 'Verwaltungsmodus' schalten und dafür sogar einen unabhängigen StackPointer verwenden. Zum OS: Ich habe mit FreeRTOS und den anderen freien Systemen noch nicht gearbeitet. Ich habe den STM32 in einem branch in Nut/OS portiert und arbeite damit. Sie Links dazu hatte ich schon genannt, glaube ich. Das Nut/OS deckt AVR, Atmel ARM7 und ARM9 und in meinem Branch auch STM32F10x ab. Es werden alle 10x unterstützt. Der STM32F20x liegt schon hier, der kommt in den nächsten 8 Wochen dazu. Du musst Dir auch überlegen, was Du am Ende machen willst. Ein RT-OS also Real-Time-OS schaltet in einer bestimmten Periode zu einem bestimmten Task. Es unterbricht also einen laufenden Task wahllos. Das erfordert bei bestimmten Dingen gewisse Vorsicht. Möchtest Du einen Datensatz dekodieren, den ein anderer Task benötigt, musst Du selbst dafür sorgen, dass der Datensatz auch vollständig ist, bevor das OS Deinen Decoder unterbricht und den anderen Task weiter machen lässt. In einem preemptiven System wie But/OS bestimmst Du in jedem Task selber, wann er die Rechenzeit an das System zurück gibt. Dein Decoder Task sagt also irgendwann, ich bin fertig und warte jetzt (auf neue Daten). Dann geht das OS hin und schaltet zum nächsten wartenden Task um. Natürlich kann man in beiden Systemen festlegen, wer öfter dran kommen soll und wer ggf. Priorität hat. Die preemptive Methode hat damit den Vorteil, dass man sie zunächst einfacher verstehen und nutzen kann. Der Nachteil ist, dass man nicht direkt einen Task mit hoher zeitlicher Präzision laufen lassen kann. Dafür werden im Nut/OS aber Timer zur Verfügung gestellt und es kommt sehr gut mit abseits programmierten Interrupts klar, was bei einem RTOS das ganze Timing zum Zittern bringen kann. Gruß, Ulrich
Gast
#2237151
Ok danke, jetzt hab ichs geschnallt ;-) Ich hatte nur die Hoffnung dass
es in dem CMSIS Ordner eine Ausführliche Doku gibt wie:
GPIO settings:
Bit Operations: GPIO_SetBits(GPIOx,GPIO_Pin_x);
.....
So dass man sich nicht alles über 3 Ebenen zusammen suchen muss.
Vielleicht gibt es das auch und ich habe es bisher übersehen, ich konnte
nur größere Funktionen dokumentiert finden.
Besten Dank für die Hilfe.
Gast
#2237192
Ich hab natürlich gerade die falschen Funktionen aufgeschrieben .... ;-P und nicht die aus der ST-LIB sry Auch wenn ich aus persönlicher Leidenschaft immer vom Nut/OS erzähle, ist es aber doch jedem frei gestellt sein lieblings OS zu wählen. Hauptsache Du blickst jetzt durch ;) Egal welchen Weg Du wählst, frag ruhig weiter, ist schließlich auch für andere interessant. Gruß, Ulrich
Gast
#2237842
Schön zu hören, ich dachte inzwischen fassen sich schon alle mit der Hand an den Kopf^^. Ich glaube wenn ich hier durch bin schreib ich ein Ideoten Tutorial für Leute die so schwer von Begriff sind wie ich ;-P. Wie gesagt das OS interessiert mich schon sehr, aber da ich am Ende was für eine Firma (Belegtarbeit) programmieren sollte und ich mir nicht sicher bin was die haben, wie es sich mit den Lizenzen verhällt und wie ausgereift das ganze ist werde ich das OS wohl eher in die Freizeit legen ^^. Und wieder eine Frage: Bindet man der Form halber die stm32f10x.h zusätzlich zur stm32f10x_GPIO.h ect. mit ein? Beide Header laufen scheinbar eigenständig, also wenn ich einen auskommentiere läuft das Programm trotzdem, laut der Coocox Demo sind aber beide eingebunden. Weiterhin finde ich es merkwürdig, dass es ohne die stm32f10x_GPIO.h überhaupt läuft, da die PINS erst dort definiert werden und im Programm genutzt werden. Scheinbar reicht das pure vorhanden sein im Verzeichniss und das Aufrufen einer der Header. (stm32f10x_GPIO.h includet ja die stm32f10x.h) Naja, das muss nix heissen. CooCox scheint da die Libraries selber irgendwie einzubinden. Man kann sich das da ja zusammenklicken. und auch ohne die Header includet zu haben kann man die Funktionen dann benutzen. stm32f10x.h Reicht mW. im allgemeinen zur Einbindung der FW-Lib aus. Die einzelnen Header für die Peripherie-Komponenten werden dort eingebunden. Allerdings ist es ein ganz schönes #include Chaos, hat aber den Vorteil, dass die LIB für die ganze SMT32F1-Serie funktioniert. (F2 hat eine andere!) Hat es jemdn schon geschafft, unter CooCox C++ zu kompilieren? Ich habe es noch nicht hinbekommen @ Ulrich P. > Ich habe den STM32 in einem branch in Nut/OS portiert und > arbeite damit. Sie Links dazu hatte ich schon genannt, glaube ich. Das interessiert mich sehr, aber ich konnte die Links nicht aus dem Text rauslesen. Wenn Du so freundlich waerst die Links hier nochmal hinzuschreiben. Gruss Ju
Gast
#2265645
Thanks Uwe. Ju Danke Uwe, habe gerade alle Rechner neu und bin daher am Installieren. Noch ein Notebook und ich bin endlich Windows-Frei! Gruß, Ulrich Ulrich P. schrieb: > Danke Uwe, > > ... und ich bin endlich Windows-Frei! > Ulrich, welche Toolchain verwendest Du und hast Du ein bestimmtes Konzept die Toolchain fuer die Arm's auf Deinen Rechnern zu installieren? Ich habe hier 7 Rechner mit der GNU Toolchain fuer die AVR's und eclipse als IDE und mir steht die Erweiterung aller Rechner auf die ARM Toolchain bevor. Ich bin noch am rumprobieren wie ich das am besten mache. Bis jetzt hab ich einen Rechner mit Ubuntu 10.04, Codesourcery und GNUArm soweit am laufen das ich binaries fuer die STM32 von der Komandozeile erstellen kann. In eclipse lassen sich Codesourcery Projekte auswaehlen und Kompilieren dann meckert aber der Linker wegen der fehlenden Linkerscripts. GNUArm hab ich in eclipse noch nicht probiert. Waere nett wenn Du ein paar Links oder Tips posten koenntest. Ju Bin zwar noch nicht bei den Toolchains (ausser dem, was ich Vorbeigehen so mitgenommen habe.) Also als Editor verwende ich sourceinsight. Der ist aber kommerziell und nur für Windows. Aber er läuft auch in der Emulation. Die Toolchain für ARM lautet unter Linux gcc-arm-linux. Das Paket findest Du, wenn Du nach armel suchst. Damit sollte dann auch alles da sein, make und so weiter ist identisch mit den üblichen binutils. Was jetzt JTAG und so weiter angeht, werde ich mich noch durchtesten. Alles Stück für Stück. Aber auf der alten Hardware war nix mehr machbar, das war einfach nur noch eine Raumheizung. Und da auf der Neuen das XP nicht mehr booten wollte... Ich wollte eh immer weg von Win, zu viel Macht zu viel Machtnix. (Daher ist hier auch AMD:INTEL mit 5:2 vertreten) Im ethernut Projekt gibt es auch ein wiki, da war neulich in der Mailingliste die Rede davon, die beschreibung der Linux Einrichtung zu überarbeiten. Ob Du diese Einrichtung mit Nut/OS oder irgend etwas anderem verwendest ist ja egal. Nut/OS setzt keine Spezialitäten auf dem Host voraus. (QT brauchst Du nur für den Nut/OS Configurator) Gruß, Ulrich
Gast
#2268192
Ich habe die neuesten Dateien und das Bildskript von http://www.yagarto.de/source/index.html herunterladen. Im Wechselspiel von ./configure Laeufen, dem Auffinden von Meldungen ueber fehlende Systemteile im config.log und dem Nachinstallieren der Teile laesst sich dann die Toolchain kompilieren. Wie auf der Ethernut Liste berichtet, haben die ethernut/branches/devnet_m3n Linkerskripte mit dem neuesten Yagarto ein Problem beim endgueltigen Linken. Einen Vorschlag zur Losung habe ich dort gepostet, mangels tiefergreifender Linkerskriptkenntnisse hoffe ich dort noch auf Rueckmeldung ob das nicht unerwuenschte Nebenwirkungne hat. Zum Download/Debuggen habe ich einen Selbstbau FTDI Jtag Adapter und lade mit Openocd/(arm-eabi-none)gdb in Flash oder Ram. Ich versuche, auch die Ethernutbibliotheken mit Debugsymbolen zu uebersetzen und den STM32F107/Openocd dazu zu bekommen, bei Einzelschritten nicht Abzustuerzen. Hi Uwe, ich habe deinen Patch gesehen und finde den in Ordnung. Ich werde den auch exakt so übernehmen, aber ich muss erst mal SVN und so weiter wieder am laufen haben. Unter Windows funktionierte der openocd einwandfrei und mit make program konnte man zuverlässig flashen, per insight-gdb habe ich mehrfach auch im Flash und RAM debugt. Das alles muss ich unter Linux erst wieder ans laufen bekommen, bin da aber sehr zuversichtlich. Das Linkerscript Problem trat plötzlich auf, etwa zwischen gcc-4.5.1 und 4.5.2 oder .3. Da wir (Firma) und ich aber nicht mitten im Projekt den Compiler wechseln, habe ich das erst mal aufgeschoben. Es war einfach keine Zeit das Problem zu lokalisieren. Aber Du hast recht, Linker Scripte sind was für jemanden, der "Vadder und Mudder erschlagen hat" :)
Gast
#2270030
Ulrich P. schrieb: > In einem preemptiven System wie But/OS bestimmst Du in jedem Task > selber, wann er die Rechenzeit an das System zurück gibt. Äh...nein... erstmal hat der Begriff Realtime OS nichts mit kooperativ oder preemptiv zu tun. Was du unter Realtime OS beschrieben hast, ist Round Robin, also Zeitscheibenverfahren, das ist wieder etwas anderes... Moderne embedded Betriebssystem wie z.B. embOS von Segger (oder Windows 7, Linux, ...) sind preemptive Betriebssystem, d.h. jede Task hat eine eigene Priorität und kann (aber muss nicht) kooperativ die CPU an den Scheduler wieder abgeben. Macht die Task dies aber nicht und wird eine Task mit höherer Priorität ausführungsbereit dann wird der Scheduler die erste Task unterbrechen und die hochpriorisierte Task starten. Ein Beispiel für ein rein kooperatives Betriebssystem ist Windows 3.11. Wenn dort eine Applikation hing, alo nicht kooperativ die CPU abgab, hing das ganze System.
Gast
#2270516
Auf Deinen Mikrokrontoller laesst Du aber nicht irgendwelche Applikationen laufen, wie auf einen PC, sondern nur wenige, genau fuer den uC kompilierte Threads. Und wenn die Threads kooperativ laufen, und nicht pre-emptive, dann macht das vieles einfacher. Danke Uwe, @Tester: Es macht wenig Sinn eine komplette Abhandlung über die verschiedenen Verzahnung innerhalb eines OS zu schreiben. Da gibt es schon genug. Wenn Du es genau wissen willst, dann gibt es Realtime garnicht. Realtime ist letztendlich, wenn etwas mit einer garantierten maximalen Abweichung in vorgegebener Zykluszeit erledigt wird. Also ist Essen auch ein Realtime-Job, denn ich habe es am liebsten 3x Täglich mit möglichst so geringer Abweichung, dass der Hunger sich nicht zu stark meldet. Die meisten OS-Hersteller bauen ihr beworbenes Realtime-OS auf preemptive Mechanismen auf, oder sie mischen. D.h. ein Task kann die CPU freigeben, bekommt sie aber auf jeden Fall all x Zyklen mal weg genommen. Es gibt sogar Lösungen, da laufen zwei OS Huckepack, also ein normales Linux und ein Realtime Kernel zusätzlich. Nut/OS macht das nicht, verbietet es einem aber auch nicht einen eigenen Timer so zu programmieren, dass er einen Interrupt erzeugt, der am System vorbei wichtige zyklische Dinge erledigt. Da die Architekturbreite größer als die gängigen zu verarbeitenden Messwerte ist, macht das in den meisten Fällen auch keine Probleme. (Race Condition) Dem normalen Anwender wird es aber reichen seine Threads einfach sauber zu schreiben, dass sie immer schön die CPU freigeben und wichtige zyklische Dinge in einem eigenen Thread zu fahren, der entsprechend klein aber hoch priorisiert ist. Gruß, Ulrich
Gast
#2270862
Uwe Bonnes schrieb: > Und wenn die Threads kooperativ laufen, und > nicht pre-emptive, dann macht das vieles einfacher. Das bestreitet auch nicht niemand, aber reines kooperatives Scheduling ist Stand der Technik von vor 15 Jahren. Du weißt eben nicht unbedingt wann ein Thread wieviel CPU braucht. Stell dir z.B. ein TCP/IP Stack vor, der dauernd nach neuen Daten pollen würde um dann, wenn keine neuen Daten da sind, die CPU kooperativ abgibt. Bei einem preemptiven OS würde die IP Task nur dann wieder angestartet, wenn neue Daten da sind (durch einen Interrupt ausgelöst). > Wenn Du es genau wissen willst, dann gibt es Realtime garnicht. Natürlich gibt es Realtime. Man muss sich nur klar machen, was das bedeutet. Realtime heißt das ein Ereignis in einer maximal versprochenen Zeit eintritt. Wenn ein OS also eine Realtime Zeit von einer Stunde definiert und diese auch einhält, dann ist das immer noch Realtime. > Dem normalen Anwender wird es aber reichen seine Threads einfach sauber > zu schreiben, dass sie immer schön die CPU freigeben und wichtige > zyklische Dinge in einem eigenen Thread zu fahren, der entsprechend > klein aber hoch priorisiert ist. <Ironie an>Stimmt, hat ja bei Windows 3.11 super funktioniert...<Ironie aus> Das reicht eben nicht wie oben schon beschrieben und ist furchtbar uneffizient. Bei einem OS will ich mir über das Timing der einzelnen Tasks eben keine Gedanken mehr machen müssen, das soll das OS für mich übernehmen, ansonsten kann ich auch bei der Superloop Programmierung in der main() bleiben. Ok, sorry, das führt vom eigentlichen Thema wohl zuweit weg, aber mich stört es immer wenn ich so Halbwissen lese ;-). Nee mit Halbwissen hat das nix zu tun. Man muss seine Aussagen auf den Empfänger abstimmen und ihn nicht mit hoch wissenschaftlichen Analysen fluten. Da ich nicht weiß, wo Paul von seinen Fähigkeiten steht, muss ich ihn irgendwo abholen. Wenn er sich unterfordert fühlt, kann er uns das sagen und wir drehen auf, kein Problem. Hier ging es um die Grundzüge eines OS/Tutorials für einen Controller. Und als zusammen gefasste Aussage (die der Fachman im Detail sicherlich aufdröseln und getrennt analysieren und bewerten würde) lag ich richtig. Und wenn Du eine 72MHz CortexM3 CPU auf ein ünliches Hobby-Projekt los lässt, dann ist es von der Rechenleistung her vollkommen egal, ob das OS preemtiv, kooperativ oder realtime-fähig ist. Es ist auf jeden Fall schnell genug. Das Entscheidende ist aber, das man bei preemtiven Systemen darauf geachtet werden muss, das größere Datenbearbeitungen Atomic erfolgen, da ein Task mit Prio n+1 einen Task mit Prio n unterbrechen kann. Ist Task Prio n+1 aber auf die Daten aus Task Prio n angewiesen, und der war noch nicht fertig, dann gibt es eine Race-Condition. Bei einem realtime OS kann man aber nicht einfach alle seine Daten in cli() und sei() klammern, dann ist es essig mit Realtime. Man muss sich also sehr viele Gedanken vorher machen. Das kooperative System hat dieses Problem nicht, denn ich gebe erst nach meiner vollständigen Datenverarbeitung die CPU zurück an den Scheduler. Außerdem kommt es erschwerend hinzu, dass 8-Bit Hobbyisten und Anfänger vor den ARM/Cortex/MIPS 32-Bit Systemen wegen vermuteter Komplexität zurück schrecken. Wenn man viele Jahre mit vielen CPUs gearbeitet hat, weiß man, dass das alles halb so wild ist, aber das bringt eben nicht jeder mit. Ein OS soll diesen Lernbegierigen den Einstieg erleichtern und das kann ein kooperatives OS sehr viel leichter tun, da es nicht bei kleinsten Unachtsamkeiten gleich nicht nachvollziehbare Merkwürdigkeiten produziert. Gleichzeitig nimmt es dem Anfänger/Umsteiger ab, sich um 40k neue register zu kümmern und jeden USART erst einmal neu anzusprechen. Kennt man sich mit einem kooperativen System dann aus, ist der Umstieg auf alles Andere sehr viel einfacher.
Gast
#2272855
Jep, in den Aussagen stimme ich dir voll und ganz zu. Trotzdem finde ich sollte man bei den Begrifflichkeiten genau bleiben, und nichts vermischen, weil dies den Anfänger dann auch nur verwirrt. Paul, ich weiß anhand Deiner Frage nicht, wer oder was Du bist, Anfänger oder alter Hase, daher, nimm den Text jetzt nicht unbedingt auf Dich gemünst. Tester (wäre schon, wenn Du Dich mal registrierst) Da stimme ich Dir auch zu, aber manche Begrifflichkeiten sind eben schwer eingänglich. Kooperativ wird jeder verstehen, da arbeitet man miteinander, aber das preemptiv unterbrechbar bedeutet, muss man vielleicht erst mal nachschlagen. Schnappt man sich dann die deutsche Übersetzung, dann wird es auch nicht einfacher, denn wenn ich meine Software schreibe, dann gehe ich davon aus, dass die Funktionen darin kooperieren. Und wenn ich mal was wichtiges machen will, dann soll das ein oder andere auch unterbrechbar sein. Ein RTOS muss zwangsläufig das Recht zur Unterbrechung haben, ich hoffe aber trotzdem dass auch unter einem RTOS meine Funktionen noch alle kooperieren und das trotz und mit Unterbrechungen. Wenn ich den interessierten Neueinsteiger nun mit den Abhandlungen zu diesen Mechanismen bombardiere, dann schult der schnell auf Gärtner oder Becker um, oder bleibt seinen 8-Bittern. Er denkt in Funktionen nicht in Prozessen oder gar Tasks und Threads. Er hat vielleicht keine Ahnung, dass eine einzelne CPU Dinge quasi-parallel machen kann und die Dinge nicht unbedingt sequenziell laufen, sondern wie Zahnrädchen ineinander greifen können. Dabei fehlt uns der Nachwuchs ganz deutlich und viele scheinen vor den CortexM3 oder ARM7/9 immer noch zurück zu schrecken. Also lassen wir mal 5 gerade sein und freuen uns über jeden, der heute nicht nur auf seine Console schaut, sondern auch hinein. Wenn die ersten LEDs blinken oder anhand zusammen kopierter Codes das erste MP3 abgespielt wird, nehmen wir ihn bei der Hand und zeigen ihm ganz behutsam die Welt der tausend Tücken eines OS/RTOS. Aber dann hat er bereits Blut geleckt und will es selber wissen. :) Ein Controller ist nur ein Controller, egal wie breit und schnell er ist. Also nicht verschrecken, sondern erst mal sanft ermutigen. Ulrich Und dann kommt noch C++ dazu ums abzurunden. gibt es eigendlich empfehlenswerte Bücher zum Programmieren von Embedded Systems? Mit dehnen ein Frischling von der Uni lernt wies richtig gemacht wird? MfG Tec Ich habe keine Ahnung :) Also die meisten Sachen über das, was ich so mit embedded Systemen anstelle, habe ich aus online Artikeln. Bzgl. RTOS war ich auch auf ein paar Seminaren im Rahmen einer Embedded World. Irgendwann hatte ich mal mit Nut/OS gespielt und das hat mir gut gefallen. Nachdem das reine Benutzen zu langweilig wurde, habe ich dann Treiber hinzugefügt und zuletzt den CortexM3 hinein portiert. Dabei habe ich dann viel gestöbert, wie man es machen kann oder sollte und auch bei anderen open Source OS/RTOS nachgesehen, wie es gehen könnte. (Aber nicht kopiert, war je keine Doktorarbeit). Aber ich habe mir auch die ca. 3000 Seiten von STM und ARM zu den Cortexen reingezogen. Natürlich Abschnittsweise :) Ulrich
Gast
#2273542
Ja, ja, hast ja recht, ist manchmal schwer wenn man jeden Tag damit arbeitet, daran zu denken das bestimmte Begriffe nicht unbedingt selbstverständlich sind. Der normale C Programmierer hat ja auch nichts mit Registern oder Startup Code zu tun, da geht's einfach bei main() los ;-). Wenn trotzdem zu dem Thema Fragen auftauchen stehe ich gerne zur Verfügung. Bücher allgemein zum Embedded programmieren kenne ich leider auch nicht, ich bin auch jemand, der erstmal jeden Fehler, den man so machen kann, einmal machen musste ;-). Für den Cortex M3 gibts ein sehr gutes Buch: http://www.amazon.com/Definitive-Guide-Cortex-M3-Embedded-Technology/dp/0750685344 Moin, den definite guide kenne ich, bin aber noch nicht zum lesen gekommen. Der scheint so das Standardwerk zu den Cortexen zu sein. Ich dachte eigendliche mehr an allgemeine Sachen wie Programmieren mit einem RTOS oder so. Aber ich glaube ich mus einfach mehr mit den Prozessoren machen dann kommt die Erfahrung. MfG Tec
Gast
#2273892
Lade dir mal von segger.com das embOS generic Manual runter. Dort sind auch die ganzen Betriebssystem Hintergründe beschrieben, die bei all OS ähnlich sind. Bin jetzt mal 30s über das Segger Manual geflogen und muss sagen, dass das richtig gut aussieht. Ist zwar auf deren embOS gemünst aber doch recht allgemein. Auch die korrekten Begrifflichkeiten nebst deren kurzer und prägnanten Definition sind vorhannden. Sieht gut aus. Finde ich auch kann man auch als Handbuch für FreeRTOS oder halt NUT/OS verwenden. Kenn jemand von euch das ODeV Konzept? http://www.stf12.org/developers/ODeV.html Finde das Recht interessant. MfG Tec
Gast
#2274378
Hört sich interessant an, so ein bisschen wie yagarto.de. Aber wenn ich schon Eclipse und OpenOCD und so weiter höre... für den privaten Einsatz weil kostenlos eine super Sache, für den proffesionellen Einsatz würde ich es nicht empfehlen, da dort die Einarbeitungszeit zu teuer ist. Das mit der Einarbeitungszeit ist relativ! Wenn Du Dich privat damit auseinander setzt und dich irgendwann fit genug fühlst Deine Kollegen zu schulen, dann kann man darauf durchaus aufsetzen. So habe ich das gemacht. Ich habe ein OS in dem ich mich sehr gut auskenne und eine openocd Konfiguration und einen gcc Compiler Setup, welches nachweislich funktioniert. Also habe ich die Dinge als Paket geschnürt und alle anderen Kollegen sind auf diesen Zug aufgesprungen. Als wir dann für ein neues Projekt von ARM7 auf CortexM3 gewechselt sind, hat sich die Frage gestellt, alles kaufen oder Portieren? Bei der Rechnung 2k€/Arbeitsplatz für Toolchain + JTAG + unbekannt Manntage Einarbeitungszeit - oder - 2..3 Mannwochen Portierung und alles Bekannte weiter verwenden.... Die Antwort war einfach. Es müssen sich ja mit Assembler und Assembler-Debugger nur ein oder zwei Leute auskennen, die anderen arbeiten mit_ und nicht _im OS. Man muss das genau durchrechnen. Und nebenbei: Warum verschenken große uC Hersteller auch mal gerne eine Hand voll Chips an Bastler oder liefern Demo-Kist zwischen 0..50€? Na, wenn der Hobby-Bastler damit spielt und sich damit auskennt, dann wird der im nächsten passenden Projekt auch eingesetzt, denn dann ist man viel schneller am Ziel. Das Argument 'hab ich mit dem oder dem Chip schon mal ausprobiert' zieht beim Chef immer. Darf ich mal fragen fuer welche Art Produkte Ihr Software auf den Arm's entwickelt wenn Ihr OS' verwendet? Ich stehe vor dem von Ulrich P. angesprochenem Problem des Einstiegs in die ARM-Welt und sehe langsam den Wald vor lauter Baeumen nicht mehr. Ich sitze in Sued America also keinem Hochpreisland wie D oder USA. Auch die Groesse der Firma haelt sich in Grenzen wo ich keine 2kEuro pro Entwickler ausgeben kann. Bis jetzt haben 8 oder 16 Bitter ausgereicht doch anstehende Projekte benoetigen mehr Rechenpower. Speziell Geschwindigkeit und Division in HW werden benoetigt. Nach der Vorentscheidung sind noch LPC und STM32 uebrig geblieben und nun bin ich am zusammenstellen der Toolchain und IDE. Bei der Recherche stolpert man zuerst ueber Codesourcery und wenn man aus der GCC-Welt stammt auch ueber gnuarm. Leider beides nicht ganz so trivial um es ans laufen zu bekommen und in eine IDE zu integrieren. Ich habe beide dazu bewegen koennen binaries fuer die entsprechende CPU zu generieren, aber die Kiddies von heute erwarten, das sie die Projekte nur zusammenklicken. Dafuer muss man Templates erstellen und da bin ich gerade am schwitzen. Als Information, fuer die STM32 waren fuer mich die aufschlussreichsten Um/Einstiegsanleitungen die von http://www.hermann-uwe.de/blog/libopenstm32-a-free-software-firmware-library-for-stm32-arm-cortex-m3-microcontrollers und die von Tec Nologic angesprochene http://www.stf12.org/developers/ODeV.html Jetzt stellt sich die eigentliche Frage. Wann OS und wann, ich nenne es mal "raw uC Programming" will aber damit bei niemanden anecken und bin offen dafuer ein anderes Termini zu verwenden. Gruss Ju So wie ich das bisher sehe, sind die Projekte bei einem 32Bit Kern schon so groß das es sich lohnt. Bsp: Wecker, ein hd44870 Display, RTC, Eingaben über Taster, usw. ein typisches 8-Bit Projekt. Prädestiniert für Superloop Programmierung. Aber, wenn du ein Tast fürs Disp hast das einfach das anzeigt was in einer Queue steht. Ein Task für die Eingaben, eins für RTC, vllt eins für die Alarmüberwachung. Mit nem RTOS brauchst du dafür nicht einen Timer(Zyklen Delay vom RTOS), Du brauchst dich nicht darum kümmern, wenn du auf eingaben Wartest das Display zu aktualisieren und die Sekunden zuzählen usw. Das erkaufst du dir damit das du dir vorher gedanken machst, wie die Tasks zusammen arbeiten müssen. Aber wenn dann noch ne SD karte oder USB oder sonst welche Perepherie dazu kommt, dann bleibt das system über sichtlicher weil jede Gruppe ein Task hat und du das Programmierst als wenn du den µC nur für diese Anwendung hast. Es bleibt nur die InterTaskKommunikation. Ich hoffe ich habe das jetzt richtig dar gestellt. MfG Tec Uwe Bonnes schrieb: > Wie auf der Ethernut Liste berichtet, haben die > ethernut/branches/devnet_m3n Linkerskripte mit dem neuesten Yagarto ein > Problem beim endgueltigen Linken. Einen Vorschlag zur Losung habe ich > dort gepostet, mangels tiefergreifender Linkerskriptkenntnisse hoffe ich > dort noch auf Rueckmeldung ob das nicht unerwuenschte Nebenwirkungne > hat. > Den Patch habe ich getestet und in den branch übernommen Uwe Bonnes schrieb: > Zum Download/Debuggen habe ich einen Selbstbau FTDI Jtag Adapter und > lade mit Openocd/(arm-eabi-none)gdb in Flash oder Ram. Ich versuche, > auch die Ethernutbibliotheken mit Debugsymbolen zu uebersetzen und den > STM32F107/Openocd dazu zu bekommen, bei Einzelschritten nicht > Abzustuerzen. Ich benutze den openocd-usb hier aus dem Shop und konnte damit sehr gut debuggen. Einzige Änderung in den scripten ist in der openocd-usb.cfg:
Ich habe den STM32 code einfach komplett mit cm3dbg übersetzt und konnte dann auch das Nut/OS selbst debuggen. Ich hoffe ich habe alle Teile vom Stub mit im Linker Script drinn. Zuletzt war ich zu faul immer von cm3 auf cm3dbg umzuschalten, da habe ich einfach in Assembler debugt. Geht irgendwann auch recht flott von der Hand, so komplex ist der thumb2 code nicht. Ulrich Juergen G. schrieb: > Nach der Vorentscheidung sind noch LPC und STM32 uebrig geblieben und > nun bin ich am zusammenstellen der Toolchain und IDE. > Eine gut Wahl. Entscheiden musst Du letztendlich einfach dadurch, welcher der Beiden für Dein Projekt die richtigen Interfaces bietet. Beide sind gut, den restlichen Markt, so er sich seid einem Jahr nicht groß verändert hat, kann man vergessen. > Bei der Recherche stolpert man zuerst ueber Codesourcery und wenn man > aus der GCC-Welt stammt auch ueber gnuarm. Leider beides nicht ganz so > trivial um es ans laufen zu bekommen und in eine IDE zu integrieren. > Ich habe beide dazu bewegen koennen binaries fuer die entsprechende CPU > zu generieren, aber die Kiddies von heute erwarten, das sie die Projekte > nur zusammenklicken. Dafuer muss man Templates erstellen und da bin ich > gerade am schwitzen. Mit diesen Kiddies gewinnt man keinen Blumentopf. Es muss eine gewisse Bereitschaft da sein, die Dinge 'hinter dem Monitor' zu verstehen, dann kann man effektiv und kostenbewusst hoch qualitative Dinge entwickeln. Sonst musst Du einen 400MHz ARM9 einsetzen um einen Wecker zu programmieren, damit die Kiddies unter .NET einfach ein paar Icons hin und her schubsen und die Uhr erscheint auf dem Display. Die, die dahinter blicken, machen das auf einem mit 32kHz laufenden 8-Bitter > Jetzt stellt sich die eigentliche Frage. > > Wann OS und wann, ich nenne es mal "raw uC Programming" will aber damit > bei niemanden anecken und bin offen dafuer ein anderes Termini zu > verwenden. > Kein Problem mit den Termini. Die Frage ist vielleicht zunächst anders herum zu stellen. Kann und will ich meine Leute für die Untiefen der Registerbanken eines Prozessors begeistern? Traue ich meinen Leuten zu, innerhalb von ein paar Tagen wenigstens mal den USART am laufen zu haben? Was machen sie um das hin zu bekommen? Die erste Frage musst Du beantworten (nee, nicht hier posten, nur drüber nachdenken) die zweite beantworte ich dir: Sie suchen in den Beispielen und kopieren den Code zusammen. Kannst Du es Dir leisten, dass sie sich für jedes Interface des Chips immer auf die Suche nach Code machen, den jemand anderes schon geschrieben hat und dann muss dieser auf die eigenen Bedürfnisse angepasst werden... Dann müssen wir das mit dem OS noch mal klären, denn da gibt es gerne Missverständnisse. Ein OS auf einem Controller ist nicht mit Windows/MacOS oder Linux zu vergleichen. Es ist viel rudimentärer und spezifischer auf die Hardware abgestimmt. Es braucht keine 2GB RAM und keine 500GB Festplatte. Und es malt auch nicht gleich bunte Fenster auf das LCD. Es stellt Dir einen Takt zur Verfügung, liefert Dir eine fertige Umgebung, in der Du mit 2 Zeilen eine Serielle Schnittstelle konfigurierst und mit printf("Hello World"); schon mal was auf dem Terminal siehst. Es sorgt dafür, dass Deine Funktionen quasi-parallel ablaufen, wenn Du sie als Threads definierst und es stellt Dir Semaphoren und Mailboxen zu Seite, damit die Threads miteinander reden können. Das ganze macht es in 1..4kB Flash. Wir haben am Anfang auch gedacht, dass wir mit 72MHz und 128k FLASH sicher hinkommen. Nut/OS und CAN und I2C und SPI und EEPROM und Sensoren und und und, das war alles schnell zusammen programmiert. Nun sind wir fast fertig und haben in den meisten Sensoren noch keine 64k voll und außerdem laufen alle mit 16MHz. Dafür nehmen sie auch keine 100mW. Wie oben schon geschrieben, haben alle Projekt Beteiligten bereist vorher Nut/OS Erfahrung auf ARM7 gesammelt, da hat einer gereicht, der die Portierung des STM32F übernommen hat und alle konnten mit exakt dem weiter Arbeiten, dass sie schon kannten. Da Du bislang kein OS eingesetzt hast, musst Du Dir die Vor- und Nachteile von Gekauft oder OpenSource gegenüber stellen. Gekauft heisst Garantie. Aber hat man als 1--2Platz Lizenzler genug Kraft eventuelle Korrekturen und Hilfestellungen zeitnah zu erhalten/durch zu setzen? Gekauft heisst aber auch mehr oder weniger gut dokumentiert, Seminare oder Schulungen verfügbar. OpenSource heisst auf Lizenzen auf zu passen. GPL ist immer mit Vorsicht zu genießen, BSD ist da viel einfacher, wenn es um das Wahren von Betriebsgeheimnissen geht und kommerzieller Einsatz im Vordergrund steht. Deswegen habe ich Nut/OS gewählt. OpenSource heisst darauf hoffen, dass bei Problemen jemand in der Mailingliste auf die Fragen antwortet. OpenSource heisst aber auch, dass ich einen Bug selber finden kann, Erweiterungen selber beisteuern kann und wegen vollständiger Quelltexte auch noch so viel von dem verstehen lernen kann, wie es mein Projekt erfordert. Ich bin mir nicht sicher, wann/wo da der Punkt erreicht ist, an dem man das eine oder das andere als schneller oder teurer ansieht. Letztendlich beginnen alle Projekte damit, dass man sich aus den verfügbaren Beispielen eines heraus pickt, dass dem projekt am nächsten kommt und es dann anpasst. Zu STM32F10x kann ich sagen, dass er in weiten Teilen von Nut/OS unterstützt wird, was fehlt kommt auf jeden Fall noch. STM32F20x kommt auch. Zu LPC habe ich aktuell nur Chips und nur ein klitzekleines Board. Sonst würde ich zumindest deren cM3 auch gleich mit portieren. Gruß, Ulrich Tec Nologic schrieb: > Es bleibt nur die InterTaskKommunikation. > > Ich hoffe ich habe das jetzt richtig dar gestellt. Richtig! Gutes Beispiel, vor dem Problem stand ich auch mal. Wie macht man es, dass man mit 3 Tasten einen MP3 Player steuert? Man braucht kurz << oder kurz >> für Track wechsel, lang << oder >> für schnelles Vorspulen. Und dann noch Start/Stop/Pause auf der mittleren Taste. Also habe ich dem Nut/OS einen Key Treiber spendiert, bei dem man einer Taste einen GPIO, eine mindest- oder maximal-Zeit und einen Handle zuweist. Nun kann man einfach einen Thread für jede der oben genannten Funktionen schreiben und die werden dann schon aufgerufen. Man kann aber auch die Handles dynamisch austauschen. Wenn also jemand ins Menü springt, dann kann die menü Funktion die Tasten kapern und für links/rechts und Enter/Escape verwenden. Sie muss sie hinterher nur zurück geben. Fuer mich stellt sich die Frage nach Open Source oder komerziell nicht wirklich. Das letzte IDE das ich gekauft habe war in den 90er Jahren das von NextStep. Und seit die schwarze Hardware verschwunden ist, ist bei mir restlos alles Open Source. Das ein OS keine bunten Bilder mahlt ist mir klar, so habe ich das auch nicht verstanden. Die Frage ist eher nach der Komplexitaet und der Freiheit. Das OS gibt mir die Freiheit mich nicht um jedes Register selbst kuemmern zu muessen, schraenkt mich aber evtl. auch ein, womit wir wieder bei der Open Source Geschichte sind. Dann werde ich mich doch erst mal in die uC OS's einlesen und ausprobieren was da so geht oder nicht geht. Warscheinlich ist das auch der beste Weg um mit den Arm's auf Tuchfuehlung zu gehen. Die Feinheiten werden dann kommen wenn ich verstehe was da eigentlich passiert. Bis dahin mal vielen Dank an alle hier im Thread. Gruss Ju
Gast
#2275235
Ein embedded OS wird dich nicht einschränken, alles was ohne OS geht, geht auch mit OS. Zumindest kenne ich das so bei SEGGER embOS. Letzlich kann man eh nur erstmal eine Trial Version runter laden und schauen, womit man am besten zurecht kommt. Bin gerade dabei mich mit openocd vertraut zu machen. Hat jemand eine Ahnung was die ausgabe Info : inter: 0.001698, inter2: 0.001699 end: 0.005701 zu sagen hat. die beiden cfg's sind angehaengt. wenn ich die Konfiguration des Targets in stm32f1x.cfg Zeile 67 und alles folgende weg lasse, kann ich mit telnet an den server gehen und die Targets von Hand konfigurieren, nur geht da keine Konfiguration des Flash mehr. Ich weiss nicht mehr wo ich suchen soll. Kann mir vielleicht jemand erklaeren was da vor sich geht. $>openocd -foocdlink.cfg -fstm32f1x.cfg Open On-Chip Debugger 0.5.0 (2011-08-26-23:19) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' 4000 kHz adapter_nsrst_delay: 100 jtag_ntrst_delay: 100 trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain stm32.cpu Info : clock speed 3000 kHz Info : inter: 0.001842, inter2: 0.001844 end: 0.007844 Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : JTAG tap: stm32.bs tap/device found: 0x06418041 (mfg: 0x020, part: 0x6418, ver: 0x0) Info : inter: 0.001698, inter2: 0.001699 end: 0.005701 Info : inter: 0.001700, inter2: 0.001701 end: 0.007678 Info : inter: 0.001779, inter2: 0.001779 end: 0.007805 Juergen G. schrieb: > Bin gerade dabei mich mit openocd vertraut zu machen. > Hat jemand eine Ahnung was die ausgabe > > Info : inter: 0.001698, inter2: 0.001699 end: 0.005701 > > zu sagen hat. Sind Zeit bzw. Zeitdifferenzen bei der Datenübertragung mittels FTDI-Baustein, vgl. Openocd Quellcodedatei ft2232.c. Können über Definition deaktiviert werden und sollten es bei einem Relase-Build auch (selbst kompiliert?). > die beiden cfg's sind angehaengt. > > wenn ich die Konfiguration des Targets in stm32f1x.cfg Zeile 67 und > alles folgende weg lasse, kann ich mit telnet an den server gehen und > die Targets von Hand konfigurieren, nur geht da keine Konfiguration des > Flash mehr. > > Ich weiss nicht mehr wo ich suchen soll. Erweiterte Ausgabe mit höherem Debuglevel (Parameter: -d3)? >(selbst kompiliert?). Ja mit ./configure --enable-ft2232_libftdi --enable-verbose --enable-verbose-jtag-io --enable-verbose-usb-io --enable-verbose-usb-comms--enable-verbose-usb-comms Die ganzen verboses sind, weil ich verstehen will was da hinter den Kulissen passiert. > (Parameter: -d3)? Hab ich auch schon probiert, nur sagt mir das was der Server da ausgibt nicht wirklich was. Das liegt warscheinlich daran, das ich noch nicht so den Durchblick habe was da eigentlich passieren muss. Im Anhang mal die Ausgabe mit -d3 Ach ja, der uC ist noch absolut Jungfrau oops, den Anhang vergessen. Ich frage mich auf was der Server da wartet. Er gibt mir die Meldungen, aber ich kann nicht mit Telnet an den Server gehen. Ju Grund für die Info inter... Ausgaben dürfte die configure-Option --enable-verbose-usb-io sein, Bedeutung erschließt sich wie schon geschrieben mit Suche nach DEBUG_USB_IO in der OpenOCD Quellcodedatei ft2232.c und anschauen des Quellcodes. Log wird durch die vielen verbose-Optionen etwas sehr überladen. Auf Anhieb nichts besonders gesehen, allerdings auch nur drübergeflogen. Im Moment weder neue OpenOCD-Version noch ein STM32-board vor Ort zum nachvollziehen. >[...]wenn ich die Konfiguration des Targets in stm32f1x.cfg Zeile 67 und >alles folgende weg lasse[...] Und was passiert wenn die Zeilen drin bleiben? Evtl. erstmal langsam mit höheren Debugleveln (-d1, -d2...) herantasten und die Ausgaben auf Warnungen und Fehler absuchen. >Im >Moment weder neue OpenOCD-Version noch ein STM32-board vor Ort zum nachvollziehen. Vielen Dank dass Du Dir trotzdem den Kopf zerbrichst. Die Jungs von der openocd mailing list scheinen alle am Strand zu liegen. Von da kommt gar nichts. > Und was passiert wenn die Zeilen drin bleiben? Evtl. erstmal langsam mit > höheren Debugleveln (-d1, -d2...) herantasten und die Ausgaben auf > Warnungen und Fehler absuchen. Wie schon erwaehnt, ich will ja bei der ganzen Sache auch dahinter kommen was beim deguggen in den Teilen so vor sich geht. Ich hab alles fuer mich erdenkliche schon versucht. Keine Ahnung wieviel mal ich den Server mit anderen Optionen neu Kompiliert habe. Und dann die -d1, -d2 und -d3 Logs studiert. Ich komm einfach nicht dahinter was der Server da versucht zu machen. Das Kuriose ist, es passiert nur dann wenn ich den Server per xx.cfg starte, und genau dann wenn die Zeile an der Reihe ist die das TARGET konfiguriert. Bis zu den TAG's kein Problem. Lass ich ab der Zeile die das Target konfiguriert alles weitere weg (auskommentiert), kann ich mit Telnet auf den Server gehen und das Target von Hand konfigurieren (alle Variablen neu setzen und die Zeile die das Target konfiguriert mit copy/paste in das Terminal) Dann sehe ich das Target und es lassen sich auch ein paar Kommandos absetzen. Nur kann ich so die flash banks nicht konfigurieren, und die brauch ich um den uC mit einem Programm zum arbeiten zu bewegen. Ju Juergen G. schrieb: >[...] > Ich hab alles fuer mich erdenkliche schon versucht. Keine Ahnung wieviel > mal ich den Server mit anderen Optionen neu Kompiliert habe. Beim letzten mal selbst bauen reichte das für meine Zwecke. Baue hier unter cygwin eine Fassung für FTDI-Herstellertreiber, erzeugte exe braucht keine cygwin-dlls.
>[...] > Das Kuriose ist, es passiert nur dann wenn ich den Server per xx.cfg > starte, und genau dann wenn die Zeile an der Reihe ist die das TARGET > konfiguriert. >[...] Was ist "es"? SRST u. TRST Einstellung geprüft und evtl. delays dazu (reset config), mit geringerem Takt versucht (adapter_khz)? Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
