Basteltip: STM32F103 DIP40 Board

Ist auf dem ESp8266 ein neuer Quarz? Wenn ja, warum?

Schöne weiße Lochraster. Passt gut zur Tasse. :-*

Ich glaube das ist kein ESP sondern ein Nrf24l01+?

Ich sehe da keinen ESP8266 sondern einen NRF24L01.

watten dat denn schrieb:
> Schöne weiße Lochraster. Passt gut zur Tasse. :-*

Jo, die gehen hier "in Serie" :-) Ist ein NRF24L01+.

Christian J. schrieb:
> Dieses Miniboard mit 128kb (Chip getauscht)

das kann man sich evtl. sparen weil nach einigen Berichten im Netz der 
F103C8 entgegen dem Datenblatt auch 128 kB Flash haben soll.
Ich habe versucht das mit dem ST-Link Utility anzusprechen, aber das 
liest die Device ID aus und blockiert den Zugriff auf >64k. Nur beim 
Erase kann man Blöcke über der 64k Grenze löschen aber das hilft 
natürlich auch nicht.
Mit dem Atollic TS habe ich ein Projekt für den F103CB gemacht und ein 
grosses Array eingebaut. Das wird aber auch nicht korrekt geschrieben 
mit GDB/ST-Link. Die zeigen zwar keine Fehlermeldungen, das Array im 
Niemandsland bringt aber den Debugger durcheinander.
Kennt jemand noch einen Trick den 'versteckten' Speicher zu nutzen?

das Arduino Zeug für STM32 habe ich nicht installiert. Ich habe aber mal 
das Flashsize Register ausgelesen und das meldet mir auch 64 kB.

1

#define FLASH_SIZE_REG 0x1FFFF7E0

2

int getFlashEnd(void)

3

{

4

  unsigned short *flashSize = (unsigned short *) (FLASH_SIZE_REG);// Address register 

5

  return ((int)(*flashSize & 0xffff) * 1024) + 0x08000000;

6

}

so wird im STM32duino bootloader die flashsize ermittelt. Dann gibt es 
möglicherweise doch C8 die nur 64k haben, eine Garantie hat man bei 
solchen Hacks natürlich nicht.

noch ein Link zu dem Thema:
http://www.eevblog.com/forum/microcontrollers/ebay-stm32f103c8-board-reports-more-memory-than-it-should/

Karsten F. schrieb:
> The trick is to tell OOCD that there are 2 banks of 64K
> And not let it probe the chip, witch only returns one bank

thanks Karsten.
until now I used Atollic TS with the built-in ST-Link debugserver. I was 
able to install OCD and configure TS to use it with my ST-Link V2 probe. 
For the configuration I used:

1

-f interface/stlink-v2.cfg -f board/stm3210b_eval.cfg

for my testapp with <64k this works fine, but my app with a large array 
I get the size error:

1

Info : device id = 0x20036410

2

Info : flash size = 64kbytes

3

Error: Memory write failure!

now I'm not sure how to use your commands. Is OCD already using the 
probing stuff or do I have to add it to the debug script?

Karsten F. schrieb:
> /Bingo

ok, got it! great stuff, it works!
thanks again!

voll krass, Speicher verdoppelt ohne Lötkolben :-)
es war einfach, in der

stm32f1x.cfg

die Zeile

1

flash bank $_FLASHNAME stm32f1x 0x08000000 0x20000 0 0 $_TARGETNAME

nach

1

# flash size will be probed

austauschen.

noch eine Idee:
damit müsste man aus ST-Link V2 auch einen V2.1 machen können?

Boah,

das ist doch Nonsense! Die Chipse kosten 6 Euro und ich brauche mit 
Profi-Equipment grad mal 5 Minuten pro Board die zu tauschen inkl. 
Reinigung vom Fluxer. Es ist doch bekannt, dass defekte Chips runter 
gelabelt werden, das war doch schon beim 386 SX Prozessor mit defektem 
CoPro so.

Ok, aber basteln macht Spass ....

Torsten C. schrieb:
> Christian J. schrieb:
>> Es ist doch bekannt, dass defekte Chips runter
>> gelabelt werden,
>
> Mit anderen Worten: Die oberen 64k sind defekt?

Ich habe bis 2002 bei einer Chipschmiede gearbeitet und da war es so. 
Defekte Speicherregionen wurden "ausgebittet" nachdem die Chip im Tester 
waren, damals war aber Flash noch was Neues.

Torsten C. schrieb:
> Mit anderen Worten: Die oberen 64k sind defekt?

Kann sein - muss nicht. Darfst Dich aber dann eben gerne auf die 
vermutung verlassen :)

rgds

Christian J. schrieb:
> das war doch schon beim 386 SX Prozessor mit defektem
> CoPro so.

Das war der 486er und der spielte preislich in einer ganz anderen Liga. 
Da hat sich das gelohnt, teilweise defekte Chips zu recyclen. Bei einem 
Chip, dessen Herstellung um 1€ liegen dürfte, lohnt sich sowas nicht. Da 
wäre der Aufwand viel zu groß und zu teuer. Da ist einfach überall das 
gleiche Silizium verbaut. Ich hab gestern mal probiert, der 
STM32F030F4P6 lacht einen auch mit 32kB Flash an. Und bei dem wird 
bestimmt nix selektiert.

Torsten C. schrieb:
> Mit anderen Worten: Die oberen 64k sind defekt?
Vielleicht nur nicht getestet, oder hält nicht alle Spezifikationen ein. 
Einmal vollschreiben mit verify und dann bei Zimmertemperatur betreiben, 
sollte das Risiko in Grenzen halten. Für kommerzielle Produkte aber 
nicht zu empfehlen.

Hallo Christian,

mir hat die Woche auch der Postbote einen St-link V2 und so ein Board 
mit einem STM32F103C8T6 gekauft.  (Ich frage mich ja, warum man sich mit 
AVR und Dragon rumschlägt, um Onchip-debugging zu bekommen und hier 
gibts das einfach so und in günstig.)

Welche Software/Bibliothek verwendest du?

Ich auf dem Board erfolgreich den LED-Blink-Test mit libopencm3 zum 
Laufen bekommen, bin mir aber nicht, ob man das verwenden will: 
http://www.libopencm3.org/wiki/Main_Page

bernd schrieb:
> Welche Software/Bibliothek verwendest du?

Die EmBitz IDE und PeriphLib von ST. Spielt alles zusammen out of the 
box.
Jo, keine Ahnung wieso man sich mit AVR rumschlägt, Käfer fahren wenn 
man einen Porsche haben kann.

bernd schrieb:
> Hallo Christian,
>
> mir hat die Woche auch der Postbote einen St-link V2 und so ein Board
> mit einem STM32F103C8T6 gekauft.  (Ich frage mich ja, warum man sich mit
> AVR und Dragon rumschlägt, um Onchip-debugging zu bekommen und hier
> gibts das einfach so und in günstig.)
>
> Welche Software/Bibliothek verwendest du?

Ich habe mir diese libopencm3 mal angeschaut ..... also was bringt das 
jetzt genau? Ich meine die StdPeriphLib erschlägt doch sowieso schon 
alles? Man bleibt kompatibel zu Code, den man aus dem Netz her kopiert 
oder Beispielen.

Ich habe diesen DIP40 Käfer jetzt mal in meinem Demo projekt einfach 
ausgereizt, einfach alles verwendet, was Sinn macht (oder auch nicht). 
Da kommen Funkdaten rein, da laufen x Timer, die RTC auch noch dabei, 
ADC sampelt über DMA, da wird ein Grafikdisplay ständig bedient usw. Und 
die CPU ist immer noch nicht "fertig", da geht noch was an Auslastung. 
Und trotz Lib Einbindung grad mal 30kb voll.

Habe heute die Kiste AVR Chips und Arduino Micros die hier noch rumlagen 
in die Bucht eingestellt. Kinder-Spielzeug gegen 32 Bit Power mit eine 
Unmenge mehr an Möglichkeiten als diese 8 Bit Zwerge...

Axel S. schrieb:
> - höhere Codedichte

Da gibt es irgendwo auf der ARM Website einen Vergleich der zeigt, dass 
ARM Thumb Code tatsächlich eine höhere Dichte als 8051 Code hat aufgrund 
der cleveren Kodierung.

Axel S. schrieb:
> - besser vorhersagbares Zeitverhalten
In Bezug auf einzelne Instruktionen ist das richtig (Pipeline), aber 
aufgrund geringerer Interrupt Latenzen, allgemein höherer Frequenz, und 
(bei STM32) mächtiger Timer Funktionen zur Verschaltung untereinander 
und mit ADC usw. lässt sich mit ARM auch sehr gut Echtzeit umsetzen.
> - potentiell geringerere Leistungsaufnahme
Ein EFM32 zB verbraucht weniger als der sparsamste AVR, und ist auch 
noch schneller mit den Rechnungen fertig bevor er wieder schlafen geht.

Ist also alles pauschal nicht so klar zu sagen :-P

> Ein EFM32 zB verbraucht weniger als der sparsamste AVR, und ist auch
> noch schneller mit den Rechnungen fertig bevor er wieder schlafen geht.

Kannst du eine konkrete Schaltung/Anwendung zeigen, an der man deine 
Aussage überprüfen kann. Insbesondere interessiert mich der Verbrauch, 
der "sparsamer" als der eines AVR-Controllers sein soll.

Bernd schrieb:
> Insbesondere interessiert mich der Verbrauch, der "sparsamer" als der
> eines AVR-Controllers sein soll.

Ich hatte einfach irgendwann mal im Datenblatt den Stromverbrauch pro 
MHz verglichen. Ich kann aber gerade nicht nachsehen welche Controller 
das jetzt genau waren...

Dr. Sommer schrieb:
> Bernd schrieb:
>> Insbesondere interessiert mich der Verbrauch, der "sparsamer" als der
>> eines AVR-Controllers sein soll.
>
> Ich hatte einfach irgendwann mal im Datenblatt den Stromverbrauch pro
> MHz verglichen. Ich kann aber gerade nicht nachsehen welche Controller
> das jetzt genau waren...

Also nur eine Bauchmeinung ohne Aussagekraft.

Bernd schrieb:
> Also nur eine Bauchmeinung ohne Aussagekraft.

Wenn ein Datenblatt für dich eine Bauchmeinung ist, was hat dann für 
dich Aussagekraft? Ein Experiment das ich unter Laborbedingungen 
zusammenschustere?
Warum ist es eigentlich so schwer zu glauben, dass ein ARM 
Prozessorkern, an dem ARM und assoziierte Firmen seit Jahren 
herumoptimieren (auch fertigungstechnisch), besser sein kann als der 
AVR, der seit ewigen Zeiten unverändert produziert wird?

Dr. Sommer schrieb:
> Warum ist es eigentlich so schwer zu glauben, dass ein ARM
> Prozessorkern, an dem ARM und assoziierte Firmen seit Jahren
> herumoptimieren (auch fertigungstechnisch), besser sein kann als der
> AVR, der seit ewigen Zeiten unverändert produziert wird?

Nu mal keine Glaubenskriege´hier, ok? Ich war in Firmen tätig, wo viel 
AVR verbaut wird und viel PIC und auch wo nur ARM, MSP etc. Sind alle 
da, machen kulturelle Vielfalt aus :-)

Mir gehts nur um Basteln, ich bin schon lange kein Entwickler mehr. Für 
den Temp. Sensor in der Butterdoese draußen war ein nackter Attiny84 die 
beste Wahl, bespielt mit der Arduino IDE, für die Basisation war es ein 
407 M4 und für das Display hier, was durch die Basis mit Daten gefüttert 
wird ist der 103C8 optimooooal.

Nachteil: Um das Gleiche zu erreichen wie mit einem AVR sind erheblich 
mehr Codezeilen nötig, Textzeilen, nicht Code. Weil der eben eine 
erheblich komplexere Peripherie hat, die auch deutlich schwerer zu 
verstehen ist als die vom AVR.

Das Display spielt auf dem Lochraster mit 16 Mhz bei ca 4cm langen 
Leitungen. Hat eine sehr gute Performance bei schnellen Grafikwechseln. 
Das kann nur ein ARM leisten. Die Mini Board habe ich jetzt für 3,65 / 
Stück bei aliexpresss bestellt, billiger gehts nicht mehr.

Einfach TOP!

Andreas R. schrieb:
> Hast den auch schon übertaktet? Beim c8 sollen ja 128 MHz gehen?

Nö. Dann werden sie sicher instabil. Der frisst bei 72 Mhz und 2 x 36 
Mhz Bussen bei mir derzeit 55mA. Das soll auch genug sein.

Dr. Sommer schrieb:
> Bernd schrieb:
>> Also nur eine Bauchmeinung ohne Aussagekraft.
>
> Wenn ein Datenblatt für dich eine Bauchmeinung ist, was hat dann für
> dich Aussagekraft? Ein Experiment das ich unter Laborbedingungen
> zusammenschustere?
> Warum ist es eigentlich so schwer zu glauben,

Ich will nicht glauben, ich will wissen. aber sass man gut sein. Du 
gehörst zu denen hier, die einfach eine Meinung raus hauen ohne dieser 
näher zu belegen. ETX.

Axel S. schrieb:
> - besser vorhersagbares Zeitverhalten


Lies mal bitte Datenblätter.
Gerade bei der wichtigen Interruptlatenz ist man beim AVR ja von 
Mondphasen und Ähnlichem abhängig. Das ist beim Cortex deutlich besser.


Christian J. schrieb:
> bernd schrieb:
>> Welche Software/Bibliothek verwendest du?
>
> Die EmBitz IDE und PeriphLib von ST. Spielt alles zusammen out of the
> box.
> Jo, keine Ahnung wieso man sich mit AVR rumschlägt, Käfer fahren wenn
> man einen Porsche haben kann.


Lustig. Porsche haben und dann Fiat-Schrott (sprich: lausige Libraries) 
dranschrauben.

Wozu diese unsägliche Library? Der M3/M4 ist doch nun wahrlich nicht 
schwer. Erst recht der STM32F103, der ja ein besonders triviales 
Exemplar der STM32-Familie ist.
Wozu also dies Bloatware?

Meister Propper schrieb:
> Wozu diese unsägliche Library?

Weil niemand nachher mehr diesen Register-Sch*** lesen kann. Logisch, 
oder? :-)

Oder soll alles so aussehen, wie mein Kot von 7 Jahren auf dem ARM7TDMI 
? Da schüttelt es einen nur.... was habe ich mir einen abgebrochen 
damals mit "Registern" :-( Und 14 Tage später schon nicht mehr gewusst 
was ich da gemacht habe.

Christian J. schrieb:
> Die Mini Board habe ich jetzt für 3,65 /
> Stück bei aliexpresss bestellt, billiger gehts nicht mehr.

Wucherpreis :D
Gibts auch für ca. 2,35€ inkl. Versand

chris schrieb:
> Wucherpreis :D
> Gibts auch für ca. 2,35€ inkl. Versand

Wooooo? Da hast Du ja recht, das ist purer Wucher, wenn es die noch 30% 
günstiger gibt! ;-)

http://de.aliexpress.com/item/STM32F103C8T6-ARM-STM32-Minimum-System-Development-Board-Module-ForArduin/32282374854.html

den hatte ich auch schon im Markt/China Schnäppchen Thread gepostet, 
kratzt gerade wieder an der 2€ Marke. Habe dort auch schon zweimal 
bestellt.
Und sein Lager kauft ihr glaube ich auch nicht so schnell leer...

Und da gibt es Leute die wollen 5€ für den nackten ausgelöteten Chip 
haben ;-)

CubeMX kann nach Gehäusen filtern, anbei eine Auswahl von "lötbaren" 
Gehäusen.

Max M. schrieb:
> Kurze Zwischenfrage: Welche IDE benutzt ihr zum Programmieren der STMs?
> Die IAR evulation license ist begrenzt auf 8kbyte Code. Das reicht
> natürlich für die 8-bit STMs aber für ARM Cortex dann bei größeren
> Sachen nicht mehr.

Du, das würde hier in Glaubenskriege ausarten.

Ohne IDE bist Du kompatibel zu jedem, große Projekte werden auch meist 
ohne IDE gemacht, zb Multikopter Software wie OpenPilot, PixHawk usw. 
damit sie eben JEDER kompilieren kann. Naja fast, denn cmake ist schon 
ne Hürde für einige IDE's, in EmBitz geht das gar nicht.

Und es sollte sich herumgesprochen haben dass CooCox (laaaaaangsam + 
100% vom Internet abhägig) und EmBitz (nur Windows) und auch EmWin ohne 
Limitierung arbeiten, da Freeware. Ich arbeite mit EmBitz, da es nur für 
mich allein ist und ich mit dem ganzen Make-File Kram und tausend 
Compileroptionen etc. nichts zu tun habe.