Forum: Mikrocontroller und Digitale Elektronik STM32 <-> AVR


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von ruepel (Gast)


Lesenswert?

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

von Uwe B. (derexponent)


Lesenswert?

>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)

von ruepel (Gast)


Lesenswert?

;) 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

von Dr. Sommer (Gast)


Lesenswert?

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.

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Lesenswert?

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.

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Angehängte Dateien:

Lesenswert?

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 einem
1
#define MyDmaRam __attribute__((section(".meinDmaRam")))
wirkt das ganze auch nicht mehr so abstrakt.

von Moritz (Gast)


Lesenswert?

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

von ruepel (Gast)


Lesenswert?

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

von ruepel (Gast)


Lesenswert?

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

von Tim  . (cpldcpu)


Lesenswert?

"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 ruepel (Gast)


Lesenswert?

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.

von STM32 Gast (Gast)


Lesenswert?

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.

von Moby (Gast)


Lesenswert?

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.

von Chris D. (myfairtux) (Moderator) Benutzerseite


Lesenswert?

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
von Bastler (Gast)


Lesenswert?

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.

von Moby (Gast)


Lesenswert?

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...

von Sean G. (atmega318)


Lesenswert?

Ich bin auch grad am umsteigen. Und ich nerv mich, dass ich mit AVR 
agefangen hab :(

von Nubi (Gast)


Lesenswert?

Erläuter doch mal! Was nervt denn so?

von Sean G. (atmega318)


Lesenswert?

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.

von Nubi (Gast)


Lesenswert?

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 :)

von Tim  . (cpldcpu)


Lesenswert?

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.

von today (Gast)


Lesenswert?

Nubi schrieb:
> dass
> das Erstellen einer in Assembler gehaltenen Anwendung

AVR war gestern, ASM war gestern!

von Tim  . (cpldcpu)


Lesenswert?

today schrieb:
> AVR war gestern, ASM war gestern!

Willkommen am Stammtisch.

von ruepel (Gast)


Lesenswert?

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ß.

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Lesenswert?

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.

von ruepel (Gast)


Lesenswert?

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...

von ruepel (Gast)


Lesenswert?

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...

von Dr. Sommer (Gast)


Lesenswert?

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.

von ruepel (Gast)


Angehängte Dateien:

Lesenswert?

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.

von ruepel (Gast)


Angehängte Dateien:

Lesenswert?

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.

von avus (Gast)


Lesenswert?

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.

Bitte 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
Noch kein Account? Hier anmelden.