Moin Mädels, i did it (beinahe zumindest!). Momentan läuft ein Timer mit 100Hz, ein Uart, das TFT, der 8080-Bus von meinem STM32F4 Discovery, wie er soll. Es gab einen kleinen Konflikt bei PD4 und PD5, weil diese Pins auch am USB-Controller und am Beschleunigungssensor vom STM32F4 Discovery dranhängen, aber die ersten Schritte sind geschafft. Als Nächstes wird die SD-Card ausprobiert, dann der Touchscreen, danach ein RFM12. Am Schluß kommt das Ethernet dran. Extrem geholfen hat mir die Seite http://mikrocontroller.bplaced.net/wordpress/?page_id=6, mit den Beispielen ist es ein Kinderspiel (öhm! ;) ), vorwärts zu kommen. Ich schaffe seit 3 Tagen mit dem STM32, und bin schon fast soweit wie mit dem AVR. Danke dem Ersteller dieser Seiten. Mein Gott. Alle Breadboards vom AVR in die Tonne treten? NEVER ;) Aber ein tüchtiges Simple-Board, das einen 144- oder 100-er STM32F407VGT6 beherbergt, das sollte man sich schon anschaffen/selber basteln. Meiner Seel, das Ding zeichnet meine Analoguhr so schnell, daß ich sogar darauf verzichtet habe, auf die obligatorische Progmem-Tabelle zugunsten Cos und Sin zu verzichten g. Im Linker sah ich im Vorbeihuschen noch einen thumb, eigentlich müßte das thumb2 heißen. Aber ich verstehe das alles sowieso nicht. Immer ran an den Speck! Die Chinesen machen keine Gefangenen. Und wir Ex-AVRler auch nicht! ;)) Grüßle Klaus
>Meiner Seel, das Ding zeichnet meine Analoguhr so schnell, daß >ich sogar darauf verzichtet habe, auf die obligatorische Progmem-Tabelle >zugunsten Cos und Sin zu verzichten wenn du dir noch ein Weihnachtsgeschenk machen willst, besorg dir das STM32F429-Disco da kannst du die Zeiger deiner Uhr (bzw. die komplette Uhr) als Bitmap darstellen weiterhin viel Spass mit den Librarys (und falls was fehlt, sag bescheid)
;) Du bist also auch im µC.net. Bisher bin ich mit Deinen vielen Libraries völlig ausgelastet g. Eine neue Discovery wäre etwas zuviel des Guten, ich habe auch noch eine Disco F0 rumliegen (wegen der vielen freien Anschlüsse; beim F4 Disco kracht es doch recht schnell, mehr als eine SPI (2) ist nicht drin). Neulich habe ich FatFS von Chan probiert. Der STM mountet nur die SDCARD, kann aber keine Files öffnen. Mich freut allerdings schon, daß er mountet. Ich habe dann Roland Riegels Lib portiert, und die geht auch auf dem STM freu Was mir noch nicht klar ist: a) Wie oft kann man den STM32F407 flashen, bis er kaputt ist, und b) kann man den Code einfach nicht flashen, sondern nur ins Ram schreiben und dort ausführen lassen? Afaik hat der STM eine von Neumann-Architektur, und ich meine bei den Debug Options in der Coocox-IDE einen enstprechenden Eintrag gesehen zu haben... Mit dem früheren PROGMEMs vom AVR ist man total versaut. Ich weiß jetzt nie, ob der STM mir bei eine const das Zeug bloß ins Ram schreibt oder echt im Flash ablegt... Hachja. Noch viel zu tun ;) Aber dank Deiner Libraries wenigstens mit einer nicht so arg eingedellten Lernkurve :p Gruß Klaus
ruepel schrieb: > a) Wie oft kann man den STM32F407 flashen, bis er kaputt ist, und Das steht im Datasheet unter "Flash memory endurance and data retention". Beim F407 sinds 10000 Zyklen. > b) kann man den Code einfach nicht flashen, sondern nur ins Ram > schreiben und dort ausführen lassen? Indem du im Linker Script eingibst, dass der Code (= .text*) in den RAM gepackt wird, in der Programming-Software ggf. eine entsprechende Option wählst (z.B. st-flash von texane braucht eine entsprechende Zieladresse), und zum Starten des Programms die BOOT* Pins entsprechend konfigurierst - alternativ manuell das VTOR im Debugger setzen und in den Code springen. > Mit dem früheren PROGMEMs vom AVR ist man total versaut. Ich weiß jetzt > nie, ob der STM mir bei eine const das Zeug bloß ins Ram schreibt oder > echt im Flash ablegt... Verwende C++11 und schreib "constexpr" an die globalen Variablen, dann kannst du dir sicher sein dass der Compiler sie berechnet und sie im Flash landen. Wenn du ganz sicher gehen willst im Map File oder Disassembly nachschauen wo es gelandet ist... Mit __attribute__((section(".text"))) solltest du das Ablegen im Programm-Speicher erzwingen können, aber das ist eigentlich ziemlich unelegant.
Der STM32F4xx hat unterschiedliche RAM's. Aus dem CCM RAM kann kein Programm ausgeführt werden. Mehr steht im Manual von ST. Man kann auch im Linkerscript definieren wo die Const hin sollen.
Angehängte Dateien:
-
STM32F4_SysArch.png
33 KB
Ich habe die Figure 1 aus dem RM0090 mal angehängt.
Darin sieht man schön wie die verschiedenen RAM Gruppen vom STM32F4xx am
Cortex-Core angeschlossen sind.
- CCM RAM, 64KB für Variablen gut geeignet, keine Befehle und keine DMA
kann darauf zugreifen
- SRAM1 ist an den I-Bus des Cortex angeschlossen, also maximal 112KB
Programm kann im RAM ausgeführt werden
- SRAM1 und SRAM2 sind DMA Tauglich. Wenn man viel mit DMA arbeitet,
dann sollten diese auf die 2 RAM-Bänke getrennt konfiguriert werden,
damit das ganze schneller läuft.
- Der ab STM32F42x hat auch ein SRAM3, der arbeitet so wie SRAM2.
Mit geschickter Parametrierung des Linker-Scriptes werden somit alle
Standard-Variablen in den CCM RAM abgelegt. Somit hat die CPU auch einen
schnelleren Zugriff auf die Daten da sie nicht warten muss bis z.B. ETH
USB DMA fertig sind.
Die Dinge die von ETH USB DMA benötigt werden können immer noch per
__attribute__((section(".meinDmaRam")))
in den anderen RAM Bereich gelegt werden ("meinDmaRam" muss natürlich
entsprechend im Linkerscript parametriert sein).
Mit einem1 | #define MyDmaRam __attribute__((section(".meinDmaRam")))
|
wirkt das ganze auch nicht mehr so abstrakt.
Hi. In der CoIde muss man nur in den Einstellungen auswählen, das der Code in den RAM soll, dass wäre dann schon. Bei einem Reset sollte der Code dann weg sein. Moritz
Liebe Leute, erstmal danke für eure Hinweise. Ist ja nun schon eine Weile vergangen, in der man nichts Elektronisches tun konnte ;) CooCox und Linkerscript? Da kann man ja gleich Eclipse nehmen :p Die verschiedenen Adressbereiche im RAM werde ich mir demnächst anschauen, so einfach wie beim Z80 ist es dann wohl doch nicht heult. Übrigens haben die AVRs natürlich noch lange nicht ausgedient (bei mir). Aber eine Synthese aus STM32 und AVR ist nicht schlecht. Wir arbeiten daran - nieder mit den PICs g! Euch allen ein frohes neues Jahr Gruß Klaus
Moritz schrieb: > In der CoIde muss man nur in den Einstellungen auswählen, das der Code > in den RAM soll, dass wäre dann schon. Bei einem Reset sollte der Code > dann weg sein. > > Moritz Ich probiere das demnächst, denn jetzt habe ich die Hardware so weit, daß es nur mehr um die Software geht. Und damit einhergehend auch das Flashen. Flashe nicht unbedingt sinnlos, aber manchmal schon. Inzwischen habe beschlossen, vom STM32F4 Discovery wegzugehen und ein (fast) eigenständiges Board zu bauen, damit die FSMC-Leitungen wirklich frei sind. (fast) bedeutet, daß ich am liebsten ein eigeness STM32-Board hätte, mit einem 100- oder 144-er F4 darauf, aber diese Dinger zu bauen (schematic, produzieren), kostet Zeit. So habe ich mir ein paar von den 100-pinnern von Mikroelektronika aus den USA bestellt (19.20 €/Stück). Die haben DIP-Anschlüsse, und ich die (fast) passenden Punkt/Streifenrasterplatinen. Was soll ich sagen: Der STM32 wird mir immer sympathischer, allerdings trifft man auch auf völlig Unbekanntes. So hatte man neulich den TX-Code für den RFM12 portiert - das Senden klappte problemlos. Allerdings das Empfangen nicht. Inzwischen geht dank zahlreicher Optimierungsmaßnahmen nichtmal mehr das Senden g Aber es gibt auch unglaublich positive Geschichten: Als fauler Mensch habe ich beim AVR gerne "sprintf" benutzt, wenn es Timing und Speicher zuliessen. Jetzt, beim STM32, sagt mir CooCox irgendwas Doofes von wegen _sbrk und daß es kein Bock hat, das Ding zu kompilieren. Da fällt einem das vor Jahren gedownloadete "xprintf" von Chan ein. Was soll man sagen: Eingebunden, läuft. Obwohl ich allein mit dem Verstehen der Funktionspointeraufrufe schon völlig überfordert wäre - die Lib von dem netten, katzenliebhabenden Japaner geht auf Anhieb. Ich werde diese Erkenntnis dazu benutzen, mein selbstgestricktes "xput" auch auf dem AVR zu ergänzen, als auch mir FATFs nochmal genauer anzuschauen. Solong, liebes AVR/STM32-Tagebuch :p
"If all you have is a hammer, every problem looks like a nail" Ich verstehe die Hysterie um den STM32F4 nicht so ganz. Die MCU ist für 90% der hier relevanten Anwendungen überdimensioniert. Wenn ein AVR nicht mehr ausreicht, gibt es auch eine Menge Cortex-M0 devices, die wesentlich anwendungsfreundlicher als ein M4 sind.
Tim schrieb: > "If all you have is a hammer, every problem looks like a nail" > > Ich verstehe die Hysterie um den STM32F4 nicht so ganz. Die MCU ist für > 90% der hier relevanten Anwendungen überdimensioniert. Wenn ein AVR > nicht mehr ausreicht, gibt es auch eine Menge Cortex-M0 devices, die > wesentlich anwendungsfreundlicher als ein M4 sind. Von meiner Seite aus lautet die Devise: Wenn ich mich schon in einen STM32 einarbeite, weshalb dann nicht in einen F4? Wobei ich die FPU vorerst nicht nutzen möchte (oder besser: kann g). Einfach einarbeiten, und die Schnelligkeit genießen. Ich mache das als Bastler; als Profi hingegen könnte ich Deinen Einwand voll und ganz verstehen. Die FPU werde ich dann verwenden, wenn es um Signalverarbeitung geht. Aber bis dahin habe ich meine Libraries erstmal auf den F4 abgestellt, was nicht schadet. Bei meinen Anwendungen kommt es auch nicht auf den Leistungsverbrauch an.
ruepel schrieb: > Aber es gibt auch unglaublich positive Geschichten: Als fauler Mensch > habe ich beim AVR gerne "sprintf" benutzt, wenn es Timing und Speicher > zuliessen. Jetzt, beim STM32, sagt mir CooCox irgendwas Doofes von wegen > _sbrk und daß es kein Bock hat, das Ding zu kompilieren. Dann binde doch einfach die fehlende Lib ein, dann meckert er auch nicht mehr und es läuft sofort. Du musst nur den Haken bei "retarget print" und "semihosting" setzen. Wobei ich sagen muss, deine Lösung klingt auch gut, evtl ist sie Ressourcen sparender.
Markus Müller schrieb: > Darin sieht man schön wie die verschiedenen RAM Gruppen vom STM32F4xx am > Cortex-Core angeschlossen sind. > - CCM RAM, 64KB für Variablen gut geeignet, keine Befehle und keine DMA > kann darauf zugreifen > - SRAM1 ist an den I-Bus des Cortex angeschlossen, also maximal 112KB > Programm kann im RAM ausgeführt werden > - SRAM1 und SRAM2 sind DMA Tauglich. Wenn man viel mit DMA arbeitet, > dann sollten diese auf die 2 RAM-Bänke getrennt konfiguriert werden, > damit das ganze schneller läuft. > - Der ab STM32F42x hat auch ein SRAM3, der arbeitet so wie SRAM2. Markus Müller schrieb: > Ich verstehe immer noch nicht was komplexer (als bei AVR, eingefügt) sein soll. Das ist einfach das Unehrliche an der Diskussion. ruepel schrieb: > so einfach wie beim Z80 (oder AVR, eingefügt) ist es dann wohl doch nicht Eben. Deshalb wirds wohl bei vielen nur mit etwas Experimentiererei und keiner fertigen, lang eingesetzten Entwicklung enden. Immerhin macht der Rausch der Geschwindigkeit Spaß. Das verstehe ich, aber mir persönlich wär die Zeit dafür zu schade.
Moby schrieb: > Markus Müller schrieb: >> Ich verstehe immer noch nicht was komplexer (als bei AVR, eingefügt) sein soll. > > Das ist einfach das Unehrliche an der Diskussion. > > ruepel schrieb: >> so einfach wie beim Z80 (oder AVR, eingefügt) ist es dann wohl doch nicht > > Eben. Deshalb wirds wohl bei vielen nur mit etwas Experimentiererei und > keiner fertigen, lang eingesetzten Entwicklung enden. Immerhin macht der > Rausch der Geschwindigkeit Spaß. Das verstehe ich, aber mir persönlich > wär die Zeit dafür zu schade. Wer sich das Referenz-Handbuch bspw. eines STM32F4 ansieht (über 1300 Seiten - und das sind nur die Dinge, die ST hinzugefügt hat - der Kern ist da noch nicht einmal drin ;-) der ist natürlich erst einmal erschlagen von den Möglichkeiten. Das ging mir (ich komme auch von der AVR-Schiene) nicht anders. ABER: man muss doch diese ganzen Sachen nicht benutzen. DMA, verschiedene RAM-Bänke mit unterschiedlichen Eigenschaften, tausende von Timern etc. kann man auch erstmal links liegenlassen :-) Man beginnt wie beim AVR erstmal mit einer blinkenden LED und sieht, dass da gar nicht so viel Unterschiede zum AVR sind. Man lernt schnell, dass man die Pins je nach erforderlicher Schaltgeschwindigkeit mit passenden Tiefpässen versehen kann, schaut sich die Flanken auf dem Oszi an und denkt: praktische Sache, das hilft Störungen zu verringern/vermeiden. Dann schaut man sich einen Timer an und merkt: ist ja gar nicht so viel anders als beim AVR Und so tastet man sich voran und ist recht schnell zumindest auf dem Level, den man bei den AVRs hatte. Nur ist da dann eben noch lange nicht Ende :-) Aber: "Klein anfangen!" heisst die Devise Wer möchte, kann mit den F4 extrem komplexe Dinge erledigen. Aber wer nur einfache Dinge tun möchte, der kann das damit eben auch tun, ohne wirklich tief einsteigen zu müssen. Und die Einstiegshürden werden immer kleiner, weil es mittlerweile wirklich gute Tutorien für Einsteiger gibt. Wir haben nun komplett auf STM32 umgestellt, weil ich nur eine Werkzeugkette und nur eine Prozessorfamilie pflegen möchte und ich dort eine immense Bandbreite an Leistungsfähigkeit abdecke, vom popligen F0 bis hin zum F4 mit FPU, direkter TFT-Ansteuerung und hastenichtgesehen. Zum Preis: Konkurrenz belebt das Geschäft. Mittlerweile bieten praktisch alle Hersteller Cortexe an - da ist die Bindung der Kunden deutlich geringer, wenn dort Preis/Leistung nicht stimmt. Wer dann seine Bibliotheken noch so aufbaut, dass hardwarespezifische Dinge ordentlich gekapselt werden, dann ist ein Wechsel kein großer Sprung mehr.
:
Bearbeitet durch Moderator
Ich bin auch auf den STM32 umgestiegen. Allerdings muss ich Tim(cpldcpu) zustimmen. Ich habe nur einen 407er im Einsatz, der Rest sind 100er oder 103er. Das schöne dran ist, dass diese pinkompatibel sind. Und für viele Dinge reicht mir die 24MHz Variante gut aus.
Möge sich der dem STM32 zuempfohlene Einsteiger bei Schwierigkeiten und rauchendem Kopf daran erinnern, daß es für sein konkretes Projekt vermutlich eine sehr viel simplere, 8 bittige Lösung gibt die sich AVR Mega/XMega nennt :) Unabhängig davon, wer die 32 Bit Leistung eines STM32 wirklich benötigt und jemals auszuschöpfen weiß soll damit glücklich werden! Der Controller, der mich zu irgendeinem Umstieg vom bewährten Alleskönner AVR veranlassen könnte, muss jedenfalls noch erfunden werden...
Ja einfach weil es nicht viel schwieriger ist, und ich mir schon oft tagelang den Kopf zerbrochen habe, wie ich meinen Code noch ein kleines bisschen optimieren könnte, damit er auf dem AVR sauber läuft. Und auf dem STM muss man halt für schnelle / unwichtige Projekte nicht gross optimieren, weil die Leistung einfach im Überfluss vorhanden ist.
Sean Goff schrieb: > weil es nicht viel schwieriger ist "ARM-Prozessoren haben eine derartig komplexe interne Architektur, dass das Erstellen einer in Assembler gehaltenen Anwendung nur für die diensterfahrenen Entwickler realisierbar ist. Durchschnittliche Programmierer sind mit dem Erlernen des Hardwareaufbaus zumeist überfordert, der Einsatz einer Hochsprache ist deswegen in den häufigsten Fällen gerechtfertigt. Arduinos basieren auf ATMega-Prozessoren aus dem Hause Atmel. Sie sind mit Sicherheit etwas komplexer als der althergebrachte PIC16F84A-Microchip -- die interne Architektur lässt sich trotzdem ohne allzu große Probleme an einem Nachmittag begreifen." aus http://www.heise.de/developer/artikel/Embedded-Programmierung-im-Umbruch-2082301.html Sean Goff schrieb: > Und auf > dem STM muss man halt für schnelle / unwichtige Projekte nicht gross > optimieren, weil die Leistung einfach im Überfluss vorhanden ist. Klingt nicht gerade nach sauberem Programmierstil :)
Nubi schrieb: > Sean Goff schrieb: >> weil es nicht viel schwieriger ist > > "ARM-Prozessoren haben eine derartig komplexe interne Architektur, ... > Arduinos basieren auf ATMega-Prozessoren aus dem Hause Atmel. Sie sind > mit Sicherheit etwas komplexer als der althergebrachte > PIC16F84A-Microchip...." Was für ein Unsinn. Assembler muss man nur auf dem PIC programmieren. Ansonsten reduziert sich das Problem darauf, die Peripherie zu verstehen. Zusätzlich gibt es wegen der 8 Bit beim AVR in C noch ein paar Fallstricke, die es beim ARM nicht gibt.
Nubi schrieb: > dass > das Erstellen einer in Assembler gehaltenen Anwendung AVR war gestern, ASM war gestern!
STM32 Gast schrieb im Beitrag #3480495: > ruepel schrieb: >> Aber es gibt auch unglaublich positive Geschichten: Als fauler Mensch >> habe ich beim AVR gerne "sprintf" benutzt, wenn es Timing und Speicher >> zuliessen. Jetzt, beim STM32, sagt mir CooCox irgendwas Doofes von wegen >> _sbrk und daß es kein Bock hat, das Ding zu kompilieren. > > Dann binde doch einfach die fehlende Lib ein, dann meckert er auch nicht > mehr und es läuft sofort. Du musst nur den Haken bei "retarget print" > und "semihosting" setzen. > Wobei ich sagen muss, deine Lösung klingt auch gut, evtl ist sie > Ressourcen sparender. Einfach die fehlende Lib einbinden, hätte ich gerne gemacht, wenn gewußt, wo man die Häkchen setzen muß g; jetzt ist es aber zu spät; das xprintf taugt gut ;) Als STM32-Newbie muß man wirklich einen Haufen Zeug gleichzeitig lernen; Speicheranbindung, Peripherie, neue Entwicklungsumgebung (wobei, Letzteres gilt nicht, der ARM-gcc ist ja zum Glück sehr ähnlich wie der AVR-gcc). Man soll auch nicht jammern, aber ich bin die letzten Tage durch die mehrere Untiefen gelatscht. Hatte die fixe Idee, "geschwind" das Beispiel von UB für den PHY von DP83848C auf LAN8720 umzustricken (ohne irgendeine Ahnung von beiden Chips bzw. Registern, wohlgemerkt). Letztendlich hat das Flashen dieses Spezialprogramms ;) dazu geführt, daß der ST-Link kaltgestellt wurde, und zwar dauerhaft und vorerst irreversibel. Da war's erstmal vorbei mit Flashen. Zum Glück hatte ich auf dem Board schon die USB-Device-Buchse verdrahtet, und 4 Stunden später die Infos und Utilities fertig, um das Ding über den Bootloader am USB zurückzuflashen. Jetzt geht der ST-Link wieder schwitz. Hab gedacht, der STM32 wäre schon kaputtgeflasht... Immerhin habe ich jetzt durch diese Episode auch gelernt, ein paar Dinge an der Hardware zu ergänzen - die UART RX-Pins von UART 1 und 3 sowie der CAN floaten nämlich noch, denen werde ich demnächst 10k Pullups verpassen, sonst klappert der Bootloader ein wenig. Der größte Mist war aber die Suche nach dem USB-Treiber. Bei ST - nichts. Mit Google nur zweifelhafte Drittanbieter-Treiber gefunden. Ich hab es letztendlich nur über Windows-Update machen können, und ich hasse das. Ich will meine Treiber höchstselbst aussuchen. Moby schrieb: [..] > ruepel schrieb: >> so einfach wie beim Z80 (oder AVR, eingefügt) ist es dann wohl doch nicht > > Eben. Deshalb wirds wohl bei vielen nur mit etwas Experimentiererei und > keiner fertigen, lang eingesetzten Entwicklung enden. Immerhin macht der > Rausch der Geschwindigkeit Spaß. Das verstehe ich, aber mir persönlich > wär die Zeit dafür zu schade. Agree. Ich werde es auch nicht zu lang eingesetzen Entwicklungen mit dem STM32 bringen; einfach deswegen, weil ich zu langsam bin (bzw. bei mir auch das komplette berufliche Umfeld fehlt). Bis ich ernsthafte Anwendungen fertig habe, gibt es schon neue Prozessoren. Aber wenn ich damals genauso gedacht hätte, wäre ich wohl beim Z80 geblieben und nie auf den AVR umgestiegen. Anfangs waren die AVRs noch ziemlich klein, ein Z80 konnte dagegen mit RAM und ROM schon richtig protzen - Speicherprobleme bekam man nicht so schnell. Trotzdem war der Vorteil des internen Flashspeichers und vor allem der eingebauten Peripherie bei den AVRs enorm. Ich persönlich schiele schon länger auf 32bit, habe mich aber bisher nicht getraut, und trotz schnellen Anfangserfolgs wird mir immer klarer, daß ich da nicht so schnell das Gefühl bekomme wie bei Z80 und AVR - nämlich die Kiste im Griff zu haben. Manche der erfolgreichen Tests (anhand der Programmbeispiele siehe oben, vor allem von UB) waren einfach Dusel - bis jetzt habe ich es z.B. nicht mehr geschafft, die RFM12 zu irgendwas zu bewegen, obwohl der eine ja schon senden konnt g. Eine Analyse des SPI-Interfaces ergab, daß MISO nicht auf Pullup, sondern Pulldown stand. Mag ich nicht, und afaik wollen SD-Karten am SDO-Pin einen High-Pegel, wenn sie initialisiert werden. So hangelt man sich eben entlang ... eines muß man aber bei aller Bescheidenheit auch sagen: Der Aufbau des Bildes bei einem 800x480 TFT ist mit dem AVR qualvoll langsam; zumindest, wenn man auch noch andere Peripherie nebenher bedienen möchte. Der Einsatz dieser todschicken TFTs ;) bedingt meiner Meinung nach auch einen flüssigen Ablauf beim pixeln, sonst ärgert man sich bloß.
ruepel schrieb: > Agree. Ich werde es auch nicht zu lang eingesetzen Entwicklungen mit dem > STM32 bringen; einfach deswegen, weil ich zu langsam bin (bzw. bei mir > auch das komplette berufliche Umfeld fehlt). Bis ich ernsthafte > Anwendungen fertig habe, gibt es schon neue Prozessoren. Nun ja, wenn man extra, wenn man mal "mehr Leistung" braucht keinen AVR sondern einen STM32 einsetzt, dann kommt wohl genau das dabei heraus. Wenn man hingegen auch für kleine Sachen schon mal einen STM32 einsetzt, dann bekommt man gleich mehr Sicherheit und versteht das ganze System auch viel schneller und kann mit dieser Erfahrung auch leichter bei den dicken Peripheriemodulen (SD-Card/USB/Ethernet) umgehen.
Markus Müller schrieb: > ruepel schrieb: >> Agree. Ich werde es auch nicht zu lang eingesetzen Entwicklungen mit dem >> STM32 bringen; einfach deswegen, weil ich zu langsam bin (bzw. bei mir >> auch das komplette berufliche Umfeld fehlt). Bis ich ernsthafte >> Anwendungen fertig habe, gibt es schon neue Prozessoren. > > Nun ja, wenn man extra, wenn man mal "mehr Leistung" braucht keinen AVR > sondern einen STM32 einsetzt, dann kommt wohl genau das dabei heraus. > Wenn man hingegen auch für kleine Sachen schon mal einen STM32 einsetzt, > dann bekommt man gleich mehr Sicherheit und versteht das ganze System > auch viel schneller und kann mit dieser Erfahrung auch leichter bei den > dicken Peripheriemodulen (SD-Card/USB/Ethernet) umgehen. Wenn man diese Argumentation verwendet, muß man also sehr früh auf neue Prozessoren umsteigen... Anyhow, die SD-Card geht seit dem Pullup von SDO wie gewohnt mit allen verfügbaren Karten (mit Roland Riegels Lib, kein STM32-SDIO), USB-Device geht inzwischen auch (UB-CDC-Lib). Der USB hat fürchterlich geklemmt, das Ding wollte einfach nicht enumerieren. Nun habe ich mal PA8,9 und 10 aus dem GPIO_Init von UB ausgemistet und jetzt geht's plötzlich g. Also zumindest mal das hin- und hersenden, was beim Abziehen passiert, hab ich noch nicht probiert. Allerdings klemmt jetzt die RTC, d.h., der USB beißt sich mit der Realtime-Clock, die löst keinen Interrupt mehr aus, wenn ich den USB zuschalte. Die schöne Analoguhr ;( Und die Chose mit den RFM12 macht mich echt fertig. Die geben keinen Mucks mehr von sich. Der eine kommuniziert wohl noch, so daß seine CLK auf 10 MHz geschraubt wird (man sieht es am CLK output), der andere kapiert gar nix mehr und dümpelt mit ein paar variierenden kHz am Ausgang rum. Käse. Da hilft jetzt nur noch Hardware-Debugging... Aber das waren ein paar lehrreiche Stunden. TFT am FMSC geht (momentan noch im 3x8Bit-Modus, aber schon fertig verdrahtet für 16bit), Touchpanel geht, SD-Card geht, UART6 geht, Bootloader über USB geht, und wahlweise USB-CDC-Device oder RTC gg. Fehlen also nur noch Fehlersuche RTC/USB, RFM12 und Programmieren vom LAN8720 (örks). Dann wäre das Board fertig getestet und es geht ans softwaremäßige Vernesteln der Devices...
Mein Einarbeitungszeitrahmen wird bereits wieder überschritten. Zwar
hatte ich großzügig 2-3 Monate veranschlagt, aber 2 davon sind fast
schon um.
Die beiden RFM12 gehen, keine Ahnung, was da los war. Inzwischen habe
ich sehr mutig PB3 vom SWD abgekoppelt und den einen RFM12 an seine
eigene SPI gehängt. Nun laufen beide wirklich unabhängig voneinander,
einer aus SPI1 und der andere zusammen mit SDCARD, Touchpanel und noch
irgendwas auf SPI3. Hätte man besser andersrum machen sollen, aber jetzt
ist es schonmal gelötet.
Eine MsgBox habe ich gebaut ;)) VisualBasic6-Kenner kennen sowas. Ist
ganz praktisch, und ein paar Icons (48*48*(565)) sind in einem
provisorischen 1-Layer-Menü implementiert. Die brauchen allerdings schon
mächtig Speicherplatz, von daher geselle ich zu dem einen RFM12 noch ein
8Mbit-Flash an SPI1, um die Icons abzuspeichern.
Könnt ihr mir bei was helfen? Ich bin da schonmal vor einem Monat
stecken geblieben. Es geht um die FatFs10a von Chan. Zwar läuft eine
andere Lib von Roland Riegel bereits sehr schön, aber ich möchte eine
Wahl. Die Low-Level-Routinen habe ich eingebaut, FatFS läuft mit non-LFN
seit heute. Aber was mich immer wieder in den Wahnsinn treibt, sind die
folgenden Fehlermeldungen con CooCox:
[cc] ..\obj\ccsbcs.o: In function `ff_convert':
[cc] C:\CooCox\CoIDE\workspace\Test\fatfs10a\option/ccsbcs.c:511:
multiple definition of `ff_convert'
[cc]
..\obj\unicode.o:C:\CooCox\CoIDE\workspace\Test\fatfs10a\option/ccsbcs.c
:511: first defined here
[cc] ..\obj\ccsbcs.o: In function `ff_wtoupper':
[cc] C:\CooCox\CoIDE\workspace\Test\fatfs10a\option/ccsbcs.c:537:
multiple definition of `ff_wtoupper'
[cc]
..\obj\unicode.o:C:\CooCox\CoIDE\workspace\Test\fatfs10a\option/ccsbcs.c
:537: first defined here
[cc] collect2.exe: error: ld returned 1 exit status
Ja, ne, is klar, daß, wenn eine Funktion in Line 511 zum ersten Mal
definiert wurde, sie auch in Line 511 zum ersten Mal definiert wurde.
Aber weshalb muß man da gleich so rummeckern und unschuldigen Bürgern
die Fertigstellung des hex-Files verweigern.
Also ich kapier's nicht.
Und am Ethernet habe ich noch garnix gemacht. Da wird man ja blöde bei
der ganzen Umstellerei...
Das sieht ein bisschen so aus als würde die selbe .c Datei mehrfach compiliert. Oder jemand war so schlau sie zu #includieren und dadurch mehrfach zu compilieren.
Angehängte Dateien:
-
DSC_5813sm.jpg
260 KB -
DSC_5816sm.jpg
280 KB -
DSC_5817sm.jpg
300 KB
Hier noch ein paar Bilder von dem "EVAL-Board" g Hab momentan vergessen, wo die Kiste mit den Buzzern ist. Für das Touchpanel wäre so ein Einrastklicken nicht schlecht. Hallo Dr. Sommer, ja so ist das wohl. Es ist nicht so, daß ich nicht versucht hätte, die beiden Funktionen samt Definition und Deklaration irgendwoanders hinzumurksen, aber irgendwie schaffe ich's heute nichtmehr, den ganzen Quark nochmal durchzugehen. Ich hatte das Problem schon vor Jahren beim AVR, irgendwie nervt es gerade. Ein grundlegendes Problem dabei dürfte sein, daß Roland Riegels Lib diese Unicode Tabellen nicht braucht. Und ich nichts von Unicode verstehe (außer daß die CJK-Staaten da halt 16 statt 7 Bit brauchen ;)) ) N8 allerseits P.s.: Sind 3x gleiche Bilder drin. Man kann das nicht mehr löschen, wenn man sich durch die Bildanhängeprozedur mal mit mehr oder weniger gewurschtelt hat. Anyhow, jetzt versteh ich's glaubich. Kommt nicht mehr vor.
Im Anhang (für mich auch als Anhangs-Test g) eine diskio.c. ChaN hatte an einer Stelle (beim Beispiel für den STM32F1) auf 16bit-SPI umgeschaltet. Ich wollte die SPI_Init nicht nochmal umstellen und habe stattdessen eine 8-bit-Routine implementiert. Nur, falls es jemand zusammen mit UBs Lib gebrauchen kann... das Beispiel läuft auf SPI3, remapped auf PC10,11,12. SD_CS auf PA15, per Software. KEIN SDIO! Da klaut der LAN8720 von dem Mikroelektronika-Steckmodul leider ein paar Datenpins.
What? Nur 6 Downloads? Dann möchte ich aber auch kein Gemecker mehr hören von wegen FatFs auf dem STM32 implemtieren sei schwierig :p In dem o.a. File diskio.c sind zwei Fehler: In der Routine 'Receive Multiple Bytes" muß es anstatt while (btr--); while (--btr); heißen. Ebenso für die Senderoutine: anstatt while (btx--); while (--btx); Dann geht das auch mit Dateien größer 32k. Sorry für das, ich bin auch erst Anfänger ( sowohl beim STM32 als auch bei FatFs). Abdrerseits ist das Ding diskio.c jetzt halbwegs anständig getestet.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.