Forum: Mikrocontroller und Digitale Elektronik Neue MCU APM32F103


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 Karsten W. (lsmod)


Bewertung
1 lesenswert
nicht lesenswert
Dies ist eine Auskopplung des Themas aus diesem Thread:
Beitrag "Re: STM32F103C8T6 - Fälschung von ST bestätigt"
(Vielleicht können die dazugehörigen Beiträge hierhin verschoben 
werden?)

Hier die wichtigsten Links dazu:

https://robotdyn.com/black-pill-apm32f103cb-128kb-flash-20kb-sram-stm32-compatible-arm-cortexr-m3-mcu-mini-board.html

https://www.aliexpress.com/item/32802556794.html

https://www.apexmic.com/en/newproduct/apm2/16

https://www.apexmic.com/uploads/tool/APM32F103x4x6x8xB%20Data%20Sheet%20V1.0.5.pdf


Um die Frage mit der FPU akzukürzen habe ich eine Anfrage bei dem 
Hersteller getätigt.
Das Ergebnis wird hier veröffentlicht, wenn eine Antwort erfolgt.

von Wasserkocher (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Running power consumption: 340mA/MHz

Donnerwetter!

von Carl D. (jcw2)


Bewertung
0 lesenswert
nicht lesenswert
Wasserkocher schrieb:
> Running power consumption: 340mA/MHz
>
> Donnerwetter!

Vermutlich mμkro-Ampere.

: Bearbeitet durch User
von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wollte mal ein 5x Pack bestellen, kommen aber noch $9 Versand dazu.
PayPal Express, also direkt über PP abwickeln ohne sich bei robotdyn 
anzumelden, schaffe ich auch nicht.

Bin ich nur unfähig?

von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
pegel schrieb:
> Wollte mal ein 5x Pack bestellen, kommen aber noch $9 Versand dazu.

Vielleicht können wir hier Bestellungen zusammenlegen und die 
Versandkosten ein wenig reduzieren?
Eine Blue-Pill wiegt mit Verpackung ca. 7g.
Zwei Stück kann man im Brief für 80 Cent weiter versenden und würde ich 
gerne nehmen.

: Bearbeitet durch User
von Bernd N (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Würde mich auch bei einer Bestellung beteiligen.

von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
Buy 1 for $1.89
Buy 5 for $1.81 each and save 4%
Buy 15 for $1.73 each and save 8%
Buy 35 for $1.65 each and save 13%

Eher nicht, denn bei 15 kommt
Delivery FedEx-IP Priority(7-14 days) $56.89
Delivery DHL (7-14 days) $57.41

Mal abgesehen von der Zoll-Problematik über $22.

: Bearbeitet durch User
von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ab 15 schlägt aber der Zoll zu.

von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
Selbst bei 7 Stück kostet der Versand $12.47 und annähernd so viel wie 
die Black Pills.
Der Zollwert wird ebenfalls gesprengt.
Das ist ja wirklich unschön ...

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Also sehen wir uns die Vorzüge noch mal an:

FPU? - habe ich nie wirklich genutzt
96MHz? - na ja, kann man mitnehmen
USB und CAN gleichzeitig? - find ich gut
128kB Flash? - ohne tricksen, ist leichter aber geht auch anders
QSPI? - das gefällt mir

Nachteil:

zurück zur StdPeriphLib.

von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
Und dann gibt es natürlich noch andere Angebote gemessen am 
Funktionsumfang:

https://www.aliexpress.com/item/4000064734991.html
5pcs STM32F401 Development Board STM32F401CCU6 STM32F4 Learning Board
US $21.00

Die Versandkosten sind direkt bei RobotDyn einfach unattraktiv.
US $18.76 für insgesamt 5 Stück.

Bei Aliexpress steht:
"Free shipping for orders over US $25.00 via the selected shipping 
method"
5pcs Shipping: US $3.23

Frage dort Mal an ...

: Bearbeitet durch User
von John Doe (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Karsten W. schrieb:
> Und dann gibt es natürlich noch andere Angebote gemessen am
> Funktionsumfang:
>
> https://www.aliexpress.com/item/4000064734991.html
> 5pcs STM32F401 Development Board STM32F401CCU6 STM32F4 Learning Board
> US $21.00
>
> Die Versandkosten sind bei RobotDyn einfach unattraktiv.


Komischer Link.
Aber ich stimme Dir zu, die einzigen Vorteile, den diese obskure MCU 
hat, sind das QSPI-Interface (aber auch das wird durch die mehr als 
doppelt so hohe Geschwindigkeit des SPI-Interfaces vom STM32F411CEU6 
relativiert) sowie der das CAN-Interface.
In allen anderen Punkten ist das Teil nachteilig:
- Komische FPU
- mehrfacher Stromverbruch
- widersprüchliche Angaben zur Taktfrquenz (72MHz oder 96MHz)
- weniger Timer
- kein I2S
- kein SDIO
- nur ein DMA Controller
- weniger Speicher auf dem angebotenen Board (im Gegensatz zu den 
€3,50-STM32F411CEU6 Boards)

Oder habe ich da etwas übersehen?

von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
Es wurde nichts übersehen.
Aber hier geht es ja im Prinzip darum eine neue Version / Derivat zu 
testen.

Wahrscheinlich ist es möglich um die 8-10 Stück über Aliexpress zu 
bestellen.
Konkrete Zusagen bitte wenn dies umgesetzt werden soll.
Die Verhandlungen laufen noch, daher muß eine konkrete Stückzahl her. 
;-)

: Bearbeitet durch User
von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Also, wenn 3 Stück insgesamt nicht mehr als einen Zehner kosten, wäre 
ich dabei.

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Karsten W. schrieb:
> Zwei Stück kann man im Brief für 80 Cent weiter versenden

Geht auch. Also bei 2 Stück max. 6,50€.

von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
Wer wäre noch mit dabei?

Für die Gesamtbestellung muß ich ohnehin in Vorkasse gehen.
Die Versandkosten werden entsprechend der Stückzahl aufgeteilt.
Weiterversand dann für 1 Euro als Brief (50g).
Auf Wunsch als Einwurfeinschreiben für 2 Euro.

Ausführung wird "APM32 NOT SOLDER" sein.
Wer zuerst kommt malt zuerst.

: Bearbeitet durch User
von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Benutzt Du PayPal?
Dann können wir in Vor-Vor-Kasse gehen.

von Bernd N (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Bin mit 2 dabei

von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
pegel schrieb:
> Benutzt Du PayPal?
> Dann können wir in Vor-Vor-Kasse gehen.

Es ist dort noch eine Konto vorhanden und kann "im Notfall" genutzt 
werden.
Die AGB und das Geschäftsgebahren dieser Firma wird jedoch abgelehnt.
Bei Aliexpress wird auf andere Art und Weise bezahlt.

von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
Bernd N schrieb:
> Bin mit 2 dabei

2-3 Stück für Pegel
2-3 für mich selbst

Es läuft eine Anfrage für ein Angebot von 8 oder 10 Stück ...

Die Bestellung sollte dann hier erst einmal ankommen.
In der aktuellen weltweiten Situation ist dies nicht (mehr) allzu 
sicher.
So erspare ich mir die Arbeit Beträge wieder erstatten zu müssen.
Der Gesamtbetrag ist ja noch überschaubar. ;-)

: Bearbeitet durch User
von Johnny B. (johnnyb)


Bewertung
0 lesenswert
nicht lesenswert
Hat jemand das Schema zum STM32F411CEU6 Board?

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Meinst Du das? Da ist nicht viel drauf.
Link zur Schaltung unten auf der Seite:

https://github.com/mcauser/WEACT_F411CEU6

von John Doe (Gast)


Bewertung
0 lesenswert
nicht lesenswert
pegel schrieb:
> Meinst Du das? Da ist nicht viel drauf.
> Link zur Schaltung unten auf der Seite:
>
> https://github.com/mcauser/WEACT_F411CEU6

Vorsicht!

Die aktuell gelieferten (habe letzte Woche 5 Stück bekommen) haben die 
Versionsnummer 2.2 und nicht 1.3 wie im Link.
Die sind leicht geändert, auch die Bauteilbezeichnungen haben andere 
Nummern.

Daher auf die Versionsnummer achten!

von John Doe (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Johnny B. (johnnyb)


Bewertung
0 lesenswert
nicht lesenswert
pegel schrieb:
> Meinst Du das? Da ist nicht viel drauf.
> Link zur Schaltung unten auf der Seite:
>
> https://github.com/mcauser/WEACT_F411CEU6

John Doe schrieb:
> Mehr Infos hier:
> https://github.com/WeActTC/MiniF4-STM32F4x1

Ja genau, danke Euch.
Das ist nützlich um die belegten Pins und Quarzfrequenz in CubeMX zu 
definieren. Dann kann man sicher innerhalb von 15 Minuten eine LED zum 
blinken bringen.

: Bearbeitet durch User
von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
Johnny B. schrieb:

> Dann kann man sicher innerhalb von 15 Minuten eine LED zum blinken bringen.

Dafür reicht auch eine gewöhnliche Blue-Pill. :-D

Spaß beiseite - wenn es vom Hersteller keine weiteren Info's zur FPU 
gibt, haben die APM32F103 keine übermäßigen Anreize zum experimentieren.
Bislang erfolgte noch keine Antwort ...

: Bearbeitet durch User
von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
/APM32F103_SDK_v1.0.0/Lib/APM32F10x_StdPeriph_Lib_V1.0.0/projects/FPU/Ar 
ithmetic/

Da gibt es ein Beispiel.
sc_math.h zeigt die möglichen Funktionen, die in einer sc_math.lib 
versteckt sind.
extern float sc_math_sin(float x);
extern float sc_math_cos(float x);
extern float sc_math_tan(float x);
extern float sc_math_asin(float x);
extern float sc_math_acos(float x);
extern float sc_math_atan(float x);
extern float sc_math_atan2(float y, float x);

extern float sc_math_invsqrt(float x);
extern float sc_math_mac(float x, float y, float z);
extern float sc_math_sum_N(float* x, unsigned char n);
extern float sc_math_sub_N(float* x, unsigned char n);
extern float sc_math_prdct(float* x, unsigned char n);
extern float sc_math_sumsq(float* x, unsigned char n);

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Damit sollte die FPU nutzbar sein.

Mehr Sorgen machen mir die fehlenden Infos über QSPI.

Aber wenn Du kalte Füße bekommst, wir müssen die nicht probieren.

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Bei den FPU Befehlen fehlen irgendwie float<->integer Wandlungen, oder?

von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
pegel schrieb:
> Damit sollte die FPU nutzbar sein.

Gut.
Liegt diese sc_math.lib als Quellcode vor?

> Mehr Sorgen machen mir die fehlenden Infos über QSPI.

Wenn es eine Rückmeldung gibt, kann man noch danach fragen.

> Aber wenn Du kalte Füße bekommst, wir müssen die nicht probieren.

Nein - keine Sorge - zur Zeit fehlt noch eine konkrete Antwort von 
RobotDyn.
Die Kosten für den Spaß sind ja echt überschaubar.

von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
pegel schrieb:
> Bei den FPU Befehlen fehlen irgendwie float<->integer Wandlungen, oder?

Wenn die FPU den IEEE 754 Standard einhält sollten diese vorhanden sein!

https://de.wikipedia.org/wiki/IEEE_754#Operationen
"Konversionen werden zwischen allen unterstützten Gleitkommaformaten 
gefordert. Bei einer Konversion in ein Gleitkommaformat mit kleinerer 
Genauigkeit muss wie schon unter Arithmetik beschrieben exakt gerundet 
werden."


Erfreulich ist auf jeden Fall wenn die trigonometrischen Funktionen 
vorhanden sind und schnell ausgeführt werden - das wäre schon ein echter 
Zugewinn.
Es fehlt noch ein logarithmus oder?

: Bearbeitet durch User
von pegel (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Karsten W. schrieb:
> Liegt diese sc_math.lib als Quellcode vor?

Leider nicht, deshalb habe ich "versteckt" geschrieben.

Habe noch was probiert, siehe Anhang.

Weiß aber nicht wie ich da ran komme.
Ein neues Projekt kann ich für den leider nicht erstellen. :(

von John Doe (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Für die FPU und QSPI sind Interruptvektoren vorhanden:
  FPU_IRQn            = 43,    /*!< FPU Global Interrupt 
*/

  QSPI_IRQn            = 44,    /*!< QSPI Global Interrupt 
*/

Beitrag #6201243 wurde vom Autor gelöscht.
von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
pegel schrieb:
> Leider nicht, deshalb habe ich "versteckt" geschrieben.

Welche unglaublichen Firmengeheimnisse mögen da drinn wohl versteckt 
sein? :-D

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Vermutlich die Hardware Adressen der FPU Register.
Lassen sich vielleicht im Debug auf ASM Ebene sogar herausfinden.

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
pegel schrieb:
> Vermutlich die Hardware Adressen der FPU Register.

Müssen ja alle im Bereich:
0x40024000 - 0x40024400
liegen.

von Richard K. (richi123)


Bewertung
4 lesenswert
nicht lesenswert
Ich habe Bilder des APM32-Dies gemacht:

https://www.richis-lab.de/STM32_05.htm

Der Chip scheint zumindest zu einem gewissen Teil von SEC-CHIP 
entwickelt worden zu sein.
Außerdem erinnert das Die entfernt an den CKS32/CS32:
https://www.richis-lab.de/STM32_03.htm
Diese Testpads innerhalb der Logik...

von Tim  . (cpldcpu)


Bewertung
1 lesenswert
nicht lesenswert
https://www.apexmic.com/en/about/company/intro

Die Firma ist damit groß geworden, Chips für Tintenpatronen zu kopieren 
um After-Market Patronen herstellen können.

Jetzt sucht man wohl nach legitimeren Geschäftsfeldern und versucht sich 
im Kopieren von Mikrocontrollern.

Ein Geschäftsmodell, welches nicht wenige Vorurteile bedient...

von MiWi (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
Ja, es ist widerlich, wie die know how Schaffer weggekickt werden. Man 
sieht doch aktuell, was eine 100% Abhängigkeit vom Chinamann für 
Probleme aufwirft. So teuer sind die STM32 doch nicht, dass hier Werbung 
für geistige Raubritter geschrieben wird.

von Uwe Bonnes (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Naja, solange die IP nicht gestohlen ist, kann man bekannte 
Schnittstellen legitim nachbauen.

von Tim  . (cpldcpu)


Bewertung
2 lesenswert
nicht lesenswert
Naja, man kann es auch anders sehen. Second sourcing war ja schon immer 
üblich. Heutzutage sind es eben nicht mehr Discretes oder LSI-Logikchips 
die nachgebaut werden sondern Mikrocontroller. ST ist groß genug 
geworden, um einen Marktstandard zu schaffen. An diesem orientieren sich 
jetzt die Neueinsteiger.

von Karsten W. (lsmod)


Bewertung
3 lesenswert
nicht lesenswert
Sind sie nicht alle nur Lizenznehmer von ARM?

Soll es angeblich nicht so etwas geben wie freie Marktwirtschaft?

Solange nicht ein fremdes Firmenlabel drauf gedruckt wird, ist es als 
ein alternatives Produkt zu betrachten.

Erstaunlich ist eher das man nicht direkt die größeren Controller-Typen 
angeht und sich auf die ohnehin sehr preiswerten Modelle stürzt.
Wie groß ist denn der Unterschied in der Chipfläche?


Der "RobotDyn Official Store" hat übrigens die letzten Fragen noch nicht 
gelesen und geantwortet ...

: Bearbeitet durch User
von auswanderer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Karsten W. schrieb:
> Soll es angeblich nicht so etwas geben wie freie Marktwirtschaft?

Also "alternatives Produkt" ist vielleicht etwas harmlos beschrieben.
ST baut die komplette Infrastruktur neben den Chips - CubeIDE, STLink, 
HAL, Application Notes, Beispiele, Videos, Tutorials, 
Entwicklungsboards. Und das alles entweder kostenlos, oder wie die 
Entwicklungsboards und STLink zu sehr fairen Preisen.
Ich erinner nur an vergangene Zeiten oder andere Firmen, wo man fuer 
einen Compiler und einen Debugger zur Bank muss um den Bausparvertrag 
aufzuloesen. Gerade wieder erlebt...Steckerserie, passt, spaeter 
vielleicht in Serie, erstmal Prototypen bauen...passende Crimpzange vom 
Hersteller 750 Euro?!?

Und dann kommt eine Firma, macht fast eine 1:1 Kopie, gibt den Dingern 
auch quasi noch den gleichen Namen, und haut sie billiger auf den Markt. 
Nutzbar mit der kompletten ST Infrastruktur, Kosten ausser Chip 
Produktion: Null.

Marktwirtschaft waere AMD/Intel x86. Die sind zwar SW-kompatibel, aber 
voellig eigenstaendige Produkte, eigener Innovation, eigener 
Infrastruktur ( Chipsaetze, Mainboards, etc. ).

APM32F103, das ist ein Chinese der einen Melcedes E250 baut, der 1:1 wie 
das Original aussieht, sich komplett gleich verhaelt, und alle 
Ersatzteile, Spezialwerkzeuge etc. des Originals passen....aber hinten 
links in der Ecke ist das eine Blech 3 Grad weiter abgewinkelt, und es 
steht ja Melcedes drauf. Und den bestellt ihr euch dann in China, und 
nutzt bei jeder Wartung das komplette Werkstattnetzwerk, Werkzeuge, 
Ersatzteile etc. vom Original.
Und jetzt machen sie eben den Melcedes E251, genau das gleiche Schema, 
aber 25 PS mehr und eine kostenlose Anhaengerkupplung dran.

Ist Geiz so Geil dass man das unterstuetzen muss? sabber lass uns eine 
Sammelbestellung machen, dann wird es NOCH BILLIGER!

Und sich dann wundern wenn sich Firmen genoetigt fuehlen brutal zu 
reagieren, siehe FTDI.

Das geht nur, weil der chinesische Staat die Hand drauf hat, waer es in 
einem anderen Land, ST wuerde aus allen legalen Kanonenrohren schiessen, 
und das zu Recht.

Ich arbeite auch mit chinesischen Zulieferern...zb. gerade letztens, DIN 
Stecker. Die machen die eben fuer einen Bruchteil der Kosten. DIN Norm 
genommen, EIGENE Werkzeuge gemacht, keinen Markennamen zu 99% 
kopiert...Marktwirtschaft.

Stellt euch einfach mal vor STM in viel Kleiner....eure Firma, ueber 
Jahre aufgebaut, 1 Chip habt ihr im Programm, alle Tools etc. gebaut. 
Und dann kommt APM um die Ecke und vertickt "kompatible" Chips billiger. 
Wo waer da euer Blutdruck?

von Michael B. (laberkopp)


Bewertung
0 lesenswert
nicht lesenswert
auswanderer schrieb:
> Marktwirtschaft waere AMD/Intel x86.

Uff, Missbrauch des Patentrechtes um unliebsame Konkurrenz klein zu 
halten, mit Marktwirtschaft hat das nichts zu tun, sondern mit 
Gesetzesmachtwirtschaft.

auswanderer schrieb:
> APM32F103, das ist ein Chinese der einen Melcedes E250 baut

Warum nutzt ST auch fertige IP-Cores in Lizenz ? Glauben die ernsthaft, 
damit hätten sie was Eigenständiges ?

Natürlich kann das jeder (nach)machen, ohne viel Gehirnschmalz.

auswanderer schrieb:
> Wo waer da euer Blutdruck?

Ich würde sagen: Wow, da ist jemand in der Lage, dieselbe Arbeit 
deutlich billiger anzubieten. Wie macht der das, warum sind meine 
eigenen Fertigungs- und Entwicklungsmethoden so kostenfressend daß ich 
das nicht auch so gut und so schnell kann ?

Und nein, es liegt nicht am Umweltschutz oder Mitarbeiterschutz. Vergiss 
das alte Märchen. In China hat man 1 Monat Probezeit, nicht ewig und 3 
Tage wie bei uns.

Gefertigt wird sowieso in einer FAB, das kann auch dieselbe sein.

von auswanderer (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Michael B. schrieb:
> Ich würde sagen: Wow, da ist jemand in der Lage, dieselbe Arbeit
> deutlich billiger anzubieten.

Ja wow.

Also du hast dir den Markt genau angeschaut, welchen Controller in 
welcher Bauform mit welchem ARM Core und welchen Peripherals zu welchem 
Preis hast genuegend Anwendungsfaelle dass man ihn verkaufen kann. Dann 
hast du Lizenzen bei ARM gekauft, Peripherals entweder eingekauft oder 
wo noetig anpassen lassen, selbst angepasst / entwickelt, z.B. eigene 
programmier / debug Logik etc. Und das Pinout...wieviele Pins, welches 
Geheause, wo welcher Pin, welche Peripherals auf die gleichen Pins 
mappen, eben so dass es fuer viele Anwendungen gut zu layouten ist und 
ueberall passt.

Und weil so ein Chip an sich komplett nutzlos ist ohne Infrastruktur, 
hast du eine komfortable IDE gebaut, HAL, Libraries, Tutorials, Code 
Beispiele, Videos, Programmieradapter, Developer Boards. Und ganz viel 
Marketing hast du auch gemacht, bis jeder Frickler der kleinsten Bude 
weiss was ein STM32 ist, Internet, Werbung, Partner, Messen...mei was 
war das teuer.

Bei der Produktion fuehrst du auch akribisch Buch, und fuehrst die 
Royalties an ARM und evtl. Andere super korrekt ab.

Und dann kommt der Chinese um die Ecke, schaut sich das an, das Business 
laeuft, kopiert sich 1:1 Bauform, Core, Peripherals vom Chip, Alles 
worueber du dir so lange und teuer Gedanken gemacht hast, und rotzt den 
nackten Chip raus, ohne sonst was dabei, weil gibts ja schon. Aber die 
Royalties fuehren sie sauber ab, natuerlich :o)

Und du kratzt dich dann am Kopf....wow, da ist jemand in der Lage, 
dieselbe  Arbeit deutlich Billiger anzubieten....was musst du nur fuer 
ein unfaehiger Dummbatz sein und was fuer ein Genie dieser Macher ist.

Du kannst ja auch mal die Gegenprobe machen...nehm doch mal einen NXP 
LXPxxxx, das ist ja quasi "genau der gleiche ARM Core" und loet den auf 
ein Board gemacht fuer einen STM32F103, dann Programmieradapter dran und 
Strom drauf. Best case passiert nichts, worst case kannst du danach das 
Zimmer lueften. Und dann sagst nochmal wow, wo ist denn nun da der 
Unterschied zum APM, ja sowas.

von pegel (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Oh, da ist ja nun aus einem kleinen Spielprojekt eine harte Grundsatz 
Diskussion geworden.

Ja, es stimmt, Industriespionage ist schlecht für Entwickler.

Aber gibt es das Wort heute eigentlich noch, wo sowieso jeder in CN 
produzieren lässt?

Man sollte nie vergessen, dass irgend welche Finanzhaie die nie genug 
bekommen können, dieses ganze Problem verursacht haben.

Deshalb lieben die das globale System. Die kleinen Arbeiter-Figuren 
lassen sich beliebig konfigurieren und austauschen.

Ich hab mir inzwischen ein paar von den oben genannten STM32F401 Boards 
bestellt. Kommen natürlich auch aus CN.

Bekommt das Geld dafür nun (zumindest teilweise) STM, oder wer?

von Karsten W. (lsmod)


Bewertung
2 lesenswert
nicht lesenswert
auswanderer schrieb:
...

Warum sind MCU's nach dem Konzept eines STM32F103 überhaupt interessant?
a) Weil sie bei gleichem oder günstigeren Preis als ein Atmel mehr 
Funktionalität bieten.
b) Weil Entwicklungs-Tools zur Verfügung stehen.
Wenn diese nicht mitgeliefert werden, kann der Chip als unbenutzbar 
betrachtet werden.

Hat Dein Melcedes die gleiche Qualität wie das Original?

Darf eine Kunde nicht entscheiden ob er Qualität oder Quantität kaufen 
will?

Was ist der Unterschied ob ein amerikanischer oder chinesischer 
Hersteller unterstützt wird?

Warte einfach nur ein wenig ab. ;-)
Sobald hier die Wirtschaft hinreichend vernichtet wurde, kann man hier 
bestimmt preiswerter als in China produzieren und es gibt eine 
STM32-Variante bald aus den eigenen Landen.
Das wäre es dann zumindest Wert zu unterstützen.


Bislang hat der Shop bei Aliexpress übrigens nicht verstanden, daß dort 
keine APM geordert werden können, weil diese ausgegraut sind ...

: Bearbeitet durch User
von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe leider auch nichts zum USB des APM32 gefunden.
Lassen wir es sein?

von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
pegel schrieb:
> Ich habe leider auch nichts zum USB des APM32 gefunden.

Soll er nicht ganz böse kompatibel zu einem STM32 sein?

> Lassen wir es sein?

Nur wenn eine Bestellung über Aliexpress nicht möglich ist.
Dann kann man in einer dämonischen Entscheidung wirklich besser 
STM32F401 bestellen. ;-)

: Bearbeitet durch User
von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Karsten W. schrieb:
> Soll er nicht ganz böse kompatibel zu einem STM32 sein?

Soll.
Ist es auch so? Es heisst ja USB und CAN gleichzeitig.
Ganz gleich kann es also nicht sein, oder?

Dämonisch war ich schon. ;)

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
pegel schrieb:
> Also sehen wir uns die Vorzüge noch mal an

Vergleich das mal mit dem STM32F303, der kann das alles auch (ausser 
QSPI und die 96 MHz) und ist HAL kompatibel.

: Bearbeitet durch User
von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Vergleich das mal mit dem STM32F303, der kann das alles auch (ausser
> QSPI und die 96 MHz) und ist HAL kompatibel.

Hier hatte ich bereits einen Vergleich angestellt, der ebenfalls keinem 
gefallen hat:
Beitrag "Re: STM32F103C8T6 - Fälschung von ST bestätigt"


Wir reden hier doch über die lustigen "neuen" Funktionen eines APM32F103 
oder?

Und davon ein paar Exemplare zu bestellen um mit diesen zu spielen.
Weil die Qualität (z.B. Stromverbrauch) wahrscheinlich nicht an die 
"Originale" heranreicht, sind diese nur interessant, wenn das 
Preis/Nutzen-Verhältnis im Vergleich stimmt.

: Bearbeitet durch User
von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
Dieses Mal hat der chinesische Händler Recht.
Habe leider ein anderes Angebot übersehen:
https://www.aliexpress.com/item/4000807291937.html
Bei 8 Stück liegt der Preis mit Versand bei $1.95 pro Stück.

Wieviele werden nun benötigt?
3 - 2 - 1 ...

: Bearbeitet durch User
von Bernd N (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Also ich nehme dir gerne 2 ab.

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gut.
Dann bin ich auch mit 2 dabei.

von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
Bernd N schrieb:
> Also ich nehme dir gerne 2 ab.

Hatten wir schon.

Also 8 Stück scheint sinnvoll.
Dann kann es sich noch einer überlegen.

von auswanderer (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Karsten W. schrieb:
> Warum sind MCU's nach dem Konzept eines STM32F103 überhaupt interessant?

Sehr gute Frage. Fuer den Hobbybastler sollte es irrelevant sein ob der 
Chip 1.20$, 2.40$ oder 3.60$ kostet.
Und fuer groessere Stueckzahlen...da ist APM32 einfach ein 
Kopierschmarotzer. Wenn man fuer die Entwicklung zu 100% auf das 
angewiesen waere was APM32 anbietet, dann waer der Chip komplett 
uninteressant fuer mittlere Stueckzahlen, weil dann der Schmerz und 
Aufwand die Kostenersparnis beim Chip wieder auffrisst.

Ich find Firmen wie z.B. Espressif toll. Die haben ihr eigenes Konzept 
gemacht, zu Beginn mit genau den typischen Schwierigkeiten dass es das 
Datasheet nur auf Chinesisch gab, nur handverlesenen Support in einem 
Forum, kaum Hilfe oder Beispiele. Aber die haben das durchgezogen und 
weiter entwickelt.

APM32 funktioniert nur, weil ST die ganze Vorarbeit geleistet hat. Und 
wenn die zu gross werden, dann muss sich ST ueberlegen ob sie ihre 
bisherige Strategie noch weiter fahren koennen. Es geht auch anders - 
Datenblatt nur gegen Aufnahme ins Lizenzprogramm fuer 100k$, Tools je 
Arbeitsplatz fuer mehrere 1000$ pro Jahr lizensieren, Programmieradapter 
die ihr Gewicht in Gold kosten, etc.

Anders gefragt...wieso macht APM32 nicht sein eigenes Ding? Also 
gleicher ARM Core ( ob die die Royalties zahlen glaub ich wenns der ARM 
CEO schriftlich bestaetigt ), eigene inkompatible Peripherals, eigenes 
Memory Mapping, eigener Bootloader, eigenes Pinout, etc.? Weil dann 
keine Sau den Chip kaufen wuerde.

APM32 wuerde Gartenstuehle und Kuechenmesser kopieren wenn der Business 
Case stimmt. Ich find es daher reichlich Assig die zu unterstuetzen, nur 
weil man den Chip nochmal 1$ billiger bekommt. Wenn ST dann die 
Hutschnur reisst und sie ihre Strategie aendern dann ist das Geschrei 
wieder gross, so wie bei FTDI damals. Die haben sich das lange genug 
angeschaut, und irgendwann eben brutal reingeschlagen - ob das gut war 
darueber kann man sich streiten, aber sowas passiert dann eben. Und ich 
hab keine Lust dass das mit ST passiert, dafuer arbeit ich viel zu 
produktiv und effizient mit ihren Produkten.

von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
auswanderer schrieb:
...

Es hält Dich doch keiner davon ab das zu tun was Du für richtig hältst.
Du hättest definitiv eine glänzende Karriere als Patentanwalt.

Mit welchem Recht willst Du darüber bestimmen was private Bastler kaufen 
und für richtig halten?

Espressif hat seinen Durchbruch nur Dank immensem Reengeneering der 
Opensource-Community gehabt.
Ebenso wie STM32, die sonst nur von "professionellen Anwendern" wie Dir 
leben müssten.

: Bearbeitet durch User
von auswanderer (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Karsten W. schrieb:
> Mit welchem Recht willst Du darüber bestimmen

Wo bestimme ich denn was? Ich hab nur eine Meinung ausgedrueckt, was ich 
von der Firma halte, und was ich davon halte die zu unterstuetzen. Ich 
halte dich von garnichts ab, wenn du die Chips weiterhin toll findest, 
nur zu. Wenn es aber zwei, drei Leute zum Nachdenken anregt, fein.

Ich hab mir auch mal "Blue Pills" bestellt, mal ging alles, mal nicht, 
keine Ahnung ob die Chips original oder kopiert waren.
Wer 8-bitter Alternativen sucht...STM32F07x hat mir gut gefallen, das 
32F072BDISCOVERY fuer 10.70$ Listenpreis. In Schaltungen setz ich 
inzwischen den STM32F030F4P6 ein, in Stueckzahlen fuer 0.70$ und weniger 
zu bekommen. Mit der gleichen Toolchain programmierbar wie Chips bis 
hoch zum Cortex M7? Find ich kein Argument mehr noch einen 8-bitter 
verbauen zu wollen.
Gibts auf Lager beim Distributor um die Ecke, same-day wenn es sein 
muss. Ist vielleicht sinnvoller als 5 gramm Hardware in einen 100 gramm 
Luftpolsterumschlag zu stecken und einzeln im Containerschiff um den 
halben Planeten zu schicken, von einer Firma die sich billig ins 
Ecosystem einer anderen reinschmarozt.

von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
auswanderer schrieb:
> Wo bestimme ich denn was? Ich hab nur eine Meinung ausgedrueckt, was ich
> von der Firma halte, und was ich davon halte die zu unterstuetzen.

Zitat:
> Ich find es daher reichlich Assig die zu unterstuetzen, nur
> weil man den Chip nochmal 1$ billiger bekommt. Wenn ST dann die
> Hutschnur reisst und sie ihre Strategie aendern dann ist das Geschrei
> wieder gross, so wie bei FTDI damals.

Wirst Du von ST als Foren-Troll bezahlt um andere zu beleidigen?

Patent-Rechte schützen immer nur die Interessen von Firmen - niemals von 
Kunden.
Ein Markenschutz zum Schutz vor Fälschungen kann anders betrachtet 
werden.

Keiner fälscht ein Produkt das nicht erfolgreich ist - das gebietet die 
Logik.
Somit hat die jeweilige Firma in jedem Fall mit ihrer Innovation bereits 
ihren Erfolg und Umsatz gehabt.

Diese Diskussion gehört in den Thread
Beitrag "STM32F103C8T6 - Fälschung von ST bestätigt"

Die APM32F103C sind nun bestellt.
Eine Antwort von Apexmic ist leider nicht eingetroffen.

: Bearbeitet durch User
von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Moin Karsten,

Karsten W. schrieb:
> Die APM32F103C sind nun bestellt.

wenn Du gerade online bist, ich bin temporär erreichbar unter:
uts14729@bcaoo.com

Dahin kannst Du deine Email Adresse senden, dann antworte ich offiziell.

von auswanderer (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Karsten W. schrieb:
> Patent-Rechte schützen immer nur die Interessen von Firmen - niemals von
> Kunden.

Karsten W. schrieb:
> Somit hat die jeweilige Firma in jedem Fall mit ihrer Innovation bereits
> ihren Erfolg und Umsatz gehabt.

Aha. Seh ich anders. Sicher geht ST nicht an drei Hobbybastlern kaputt. 
Aber APM32 wird auch nicht fuer drei Hobbybastler aufgelegt.
Eine Folge von sowas ist zb. dass eine Firma ein Design basierend auf 
STM32 macht, mit allen Resourcen, Tools, etc. und vielleicht noch 
ordentlich den Support von ST nutzt. Und wenn das Produkt fertig ist, 
geben die das zum Auftragsfertiger, die z.B. auch gern das komplette 
Sourcing, Lagerhaltung und Bestueckung von Bauteilen uebernehmen. Und 
der fragt dann vielleicht: der Chip da....muss das der sein, oder kann 
ich das was "kompatibles" fur 1$ weniger pro Stueck einbauen?

Was soll dann ST machen...sagen och, wir haben ja "bereits unseren 
Erfolg und Umsatz gehabt", lass uns so weiter machen?

Nein, ich bin kein "von ST bezahlter Foren-Troll". Ich bin jemand der 
mit STM32 arbeitet, und der froh darueber ist wie ST das Produkt bisher 
positioniert. Und das ist mein ganz starkes Interesse als Kunde dass es 
so bleibt, dass die nicht morgen fuer IDE+HAL einen Betrag verlangen wo 
ich erstmal einen Bankkredit brauch.
Ein Gegenbeispiel waere Qualcomm...ein Bekannter von mir hat eine 
Startup, der Weg seine viel zu teuere BOM zu reduzieren war ein 4G SOC 
von Qualcomm. Letztendlich ging das auch, aber nicht aus eigener Kraft, 
Qualcomm ist so ein zugenagelter Laden, da darfst du erstmal einen 
obszoenen Geldbetrag auf den Tisch legen bis die ueberhaupt mit dir 
reden. Das kann dann das Ergebnis sein...fuer eine grosse Firma kein 
Problem, allen Anderen wird schlichtweg der Zugriff auf die Technologie 
verwehrt den sie braeuchten. Und wenn man nicht darueber nachdenkt wie 
das wirtschaftlich zusammenhaengt wuerde man sagen: Qualcomm ist genau 
der Grund wieso Kopieren als Notwehr sein muss.

von Karsten W. (lsmod)


Bewertung
-2 lesenswert
nicht lesenswert
auswanderer schrieb:
> Und der fragt dann vielleicht: der Chip da....muss das der sein, oder kann
> ich das was "kompatibles" fur 1$ weniger pro Stueck einbauen?

Was ist daran verkehrt?
Wenn es ein sehr preiswertes Produkt werden soll macht das Sinn.
Soll es ein Qualitäts-Produkt mit einem höheren Verkaufspreis werden,
macht es Sinn lieber vorsichtig auf einen bewährten STM32 zu setzen.

> Was soll dann ST machen...sagen och, wir haben ja "bereits unseren
> Erfolg und Umsatz gehabt", lass uns so weiter machen?

Eine neue Innovation entwickeln, weil sie das viel besser können als die 
Chinesen.
Die Chinesen können besser und günstiger in Serie produzieren.

Wo gibt es die Garantie ein Leben lang mit einem Produkt Geld verdienen 
zu können?

: Bearbeitet durch User
von Carl D. (jcw2)


Bewertung
2 lesenswert
nicht lesenswert
Ich denke es gibt 2 Dinge zu unterscheiden.
Wer mehr oder weniger STM32-kompatible Chips als Originale labelt, der 
it ein Fälscher.
Wer die selben IP-Komponenten (ARM-Core/Peripherie-Blöcke) wie STM auf 
einem eigenen Chip verbaut, der nicht als STM-Original gelabelt ist, 
dann ist daran nichts auszusetzen.
Wenn man als "Originalhersteller" das nicht will, dann muß man sich um 
Exklusivlizensen bemühen, die dann eben deutlich teuerer (bis 
unbezahlbar im Falle von ARM sind).

von John Doe (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Karsten W. schrieb:
> Wo gibt es die Garantie ein Leben lang mit einem Produkt Geld verdienen
> zu können?


In der Musik, sogar über den Tod hinaus... ;)

von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
John Doe schrieb:
> In der Musik, sogar über den Tod hinaus... ;)

Stimmt - aber soll man Kunst als ein Produkt betrachten? :-)


Die Bestellung ist nun unterwegs:
China Post Registered Air Mail LE731309808CN

: Bearbeitet durch User
von Karsten W. (lsmod)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Hier ist der disassemblierte Code der FPU library.
Disassembliert mit arm-elf-objdump -D -b binary -marm sc_math.lib

Vielleicht kann man daraus schon Mal einige Rückschlüsse gewinnen?

von pegel (Gast)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Karsten W. schrieb:
> Hier ist der disassemblierte Code der FPU library.

Also meine Version im Anhang gefällt mir irgendwie besser.
Ganz unten erscheint sogar die FPU Hardware Adresse.

arm-none-eabi-objdump -d sc_math.lib

von Carl D. (jcw2)


Bewertung
1 lesenswert
nicht lesenswert
pegel schrieb:
> Karsten W. schrieb:
>> Hier ist der disassemblierte Code der FPU library.
>
> Also meine Version im Anhang gefällt mir irgendwie besser.
> Ganz unten erscheint sogar die FPU Hardware Adresse.
>
> arm-none-eabi-objdump -d sc_math.lib

Ok, 32-Bit-Float,
5 32-Bit-Register:
0: Opcode
1: Status,  Bit0: Busy
2: Result
3: Op1
4: Op2

Opcodes:
  1: asin
  3: acos
  5: atan
  7: atan2
  9: sin
 11: cos
 13: tan
...
289: fadd
293: fsub
295: fmul
 45: fdiv
...

Und als Fan von Compilern muß ich trotzdem sagen:
hätten sie das in Assembler geschrieben, hätten sie etwas Code gespart 
und weniger Register gebraucht. Für eine Lib auf dieser tiefen Ebene 
hätte ich auf C verzichtet. Aber das ganze ist ja sehr übersichtlich und 
kann problemlos verbessert werden. Ich hätte nicht erwartet, daß dieses 
Ding im Bereich Trigonometrie so viel bietet und nehme mein Kritik von 
weiter oben zurück. Wenn jemand so ein Teil hat, dann wäre interessant 
wie schnell die FPU rechnet.

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@ Carl D.

Als ASM Nichtkenner müsste ich jeden Befehl erst einmal studieren.

Würdest Du evtl. für die Funktion sc_math_sin Zeilenweise erklären was 
da genau passiert?

Das wäre vorab sehr hilfreich.

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das geht schon beim ersten Befehl los:

mov  r1, r0

Es wird etwas in das Register r1 geladen.
Aber was? Der float Wert, oder die Adresse auf den Wert?

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
0 lesenswert
nicht lesenswert
pegel schrieb:
> Es wird etwas in das Register r1 geladen.
> Aber was? Der float Wert, oder die Adresse auf den Wert?

Da wird r0 nach r1 kopiert.
Da dies der erste Befehl der Funktion ist befindet sich in r0 der erste 
Übergabewert der Funktion (calling convention).

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mw E. schrieb:
> Da dies der erste Befehl der Funktion ist befindet sich in r0 der erste
> Übergabewert der Funktion (calling convention).

Also der Wert selbst und nicht seine Adresse, richtig?

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
0 lesenswert
nicht lesenswert
pegel schrieb:
> Mw E. schrieb:
>> Da dies der erste Befehl der Funktion ist befindet sich in r0 der erste
>> Übergabewert der Funktion (calling convention).
>
> Also der Wert selbst und nicht seine Adresse, richtig?

richtig!

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich würde warten bis das Teil da ist und dann den Debugger die Arbeit 
erledigen lassen.
Dann brauche ich nur die Register und Inhalte der Speicheradressen 
beobachten.

Es kann aber auch nicht schaden, wenn man schon etwas vorab versteht.

von Carl D. (jcw2)


Bewertung
0 lesenswert
nicht lesenswert
pegel schrieb:
> Ich würde warten bis das Teil da ist und dann den Debugger die Arbeit
> erledigen lassen.
> Dann brauche ich nur die Register und Inhalte der Speicheradressen
> beobachten.
>
> Es kann aber auch nicht schaden, wenn man schon etwas vorab versteht.

Naja, ich hab schon /370, 8048, 8051, Z80, 8086, 386, ARM in Assembler 
programmiert, und hab ein paar Sachen auf Cortext-M ausprobiert, da muß 
man beim debuggen verstehen wie der Compiler Funktionen aufruft. R0..R3 
sind z.B. die ersten 4 Parameter, R0 gibt Werte bis 32-Bit Größe zurück, 
...
Mal schauen, ob ich heute noch Zeit finde vom Pad zum Rechner zu 
wechseln und die Lib mal runterzuschreiben. Immerhin scheinen die 
Funktionen zum GCC zu passen, d.h. wenn der Soft-FP-Code erzeugt, dann 
werden die FP-Routinen durch das "FP-Device" ausgeführt. Spart auch 
Flash.

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Bei Z80 war ich auch mal dabei. Ist aber schon ein wenig her.

Carl D. schrieb:
> Soft-FP-Code

Das soll eben nicht passieren.
Es geht nur um die Funktion:
00000000 <sc_math_sin>:
   0:  4601        mov  r1, r0
   2:  2009        movs  r0, #9
   4:  4afe        ldr  r2, [pc, #1016]  ; (400 <__wrap___ltsf2+0x2a>)
   6:  6010        str  r0, [r2, #0]
   8:  4610        mov  r0, r2
   a:  60c1        str  r1, [r0, #12]
   c:  bf00        nop
   e:  48fc        ldr  r0, [pc, #1008]  ; (400 <__wrap___ltsf2+0x2a>)
  10:  6840        ldr  r0, [r0, #4]
  12:  f000 0001   and.w  r0, r0, #1
  16:  2800        cmp  r0, #0
  18:  d0f9        beq.n  e <sc_math_sin+0xe>
  1a:  48f9        ldr  r0, [pc, #996]  ; (400 <__wrap___ltsf2+0x2a>)
  1c:  6880        ldr  r0, [r0, #8]
  1e:  4770        bx  lr


Ab:
400:  40024000   .word  0x40024000
befindet sich die FPU Hardware.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
1 lesenswert
nicht lesenswert
Ich bin mal so nett und erfülle deinen Wunsch:

Die Funktion ist float sc_math_sin(float value);
also r0 = value
00000000 <sc_math_sin>:
   0:  4601        mov  r1, r0
   r0 in r1 sichern, also kopieren
   
   2:  2009        movs  r0, #9
   die Zahl 9 als immediate nach r0 schreiben mit statusflags update (das s) (wozu auch immer)
   
   4:  4afe        ldr  r2, [pc, #1016]  ; (400 <__wrap___ltsf2+0x2a>)
   einen Wert nach r2 laden
   ARM packt Konstanten gerne in den Code rein, daher ist der Programmcounter hier vorhanden
   pc + 1016 ist die Adresse zum laden, aber ARM ist pipelined, also pc ist schon pc+4!
   adresse: pc (ist 4) + 4 + 1016 = 1024 = 0x400
   und da liegt die Basiadresse der FPU Register! (=0x40024000)
   -> r2 = Basisadresse der FPU Register
   
   6:  6010        str  r0, [r2, #0]
   jetzt wird die 9 in das erste memory mapped Register der FPU geschrieben
   also der Opcode = 9 für sinus
   
   8:  4610        mov  r0, r2
   jetzt wird r2 nach r0 kopiert
   
   a:  60c1        str  r1, [r0, #12]
   jetzt wird der floatwert in ein memory mapped FPU Register geschrieben
   Weil das 32Bit register sind: 12/4 -> Register 3 -> Op1 der FPU
   
   c:  bf00        nop
   1 Takt nix tun
   
   e:  48fc        ldr  r0, [pc, #1008]  ; (400 <__wrap___ltsf2+0x2a>)
   schonwieder die Basiadresse laden obwohl die immernoch in r2 steht...
   
  10:  6840        ldr  r0, [r0, #4]
  jetzt ein FPU Register laden, das memory mapped FPU Register 1 (Status)
  
  12:  f000 0001   and.w  r0, r0, #1
  verunden mit 1, also das Busy bit angucken
  
  16:  2800        cmp  r0, #0
  das busy bit mit 0 vergleichen und statusflags setzen
  
  18:  d0f9        beq.n  e <sc_math_sin+0xe>
  branch equal, also wenn busybit == 0, dann nach 0xe springen
  (Pollschleife bis die FPU fertig ist)
  
  1a:  48f9        ldr  r0, [pc, #996]  ; (400 <__wrap___ltsf2+0x2a>)
  schonwieder die Basiadresse laden obwohl die immernoch in r2 steht...
  
  1c:  6880        ldr  r0, [r0, #8]
  jetzt ein FPU Register laden, das memory mapped FPU Register 1 (Status)
  Weil das 32Bit register sind: 8/4 -> Register 2 -> Result der FPU
  r0 ist laut calling convention das Rückgaberegister
  
  1e:  4770        bx  lr
  branch exchange
  nach LinkRegister springen, das wurde vom caller gesetzt (branch and link)
  also zurückspringen

Der schiebt da öfter sinnlos Register durch die Gegend.
auch die Basiadresse wird öfter geladen.
Da hat wohl wer nicht mit -02 kompiliert.

: Bearbeitet durch User
von pegel (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Vielen Dank.

Ich habe auch ein wenig selbst probiert, das kam dabei raus:
00000000 <sc_math_sin>:

r1 <- Wert
   0:  4601        mov  r1, r0

r0 <- 0x00000009
   2:  2009        movs  r0, #9; sin Opcode

r2 <- [0x40024000]; Inhalt von Adresse 0x40024000
   4:  4afe        ldr  r2, [pc, #1016]  ; (400 <__wrap___ltsf2+0x2a>)

r0 -> [0x40024000]; r0 auf Adresse 0x40024000 ablegen (9:sin)
   6:  6010        str  r0, [r2, #0]

r0 <- r2; vorheriger Inhalt von Adresse 0x40024000
   8:  4610        mov  r0, r2

r1 -> r0+12; r1 in vorherigem Inhalt von Adresse 0x4002400C (Wert in OP1)
   a:  60c1        str  r1, [r0, #12]

   c:  bf00        nop

r0 <- [0x40024000]; Inhalt von Adresse 0x40024000
   e:  48fc        ldr  r0, [pc, #1008]  ; (400 <__wrap___ltsf2+0x2a>)

r0 <- [0x40024000+4]; Status Register
  10:  6840        ldr  r0, [r0, #4]

logisch "und" r0,1; Busy?
  12:  f000 0001   and.w  r0, r0, #1
r0 = 0?
  16:  2800        cmp  r0, #0

wenn nicht, springe zu e:
  18:  d0f9        beq.n  e <sc_math_sin+0xe>

r0 <- [0x40024000] 
  1a:  48f9        ldr  r0, [pc, #996]  ; (400 <__wrap___ltsf2+0x2a>)

r0 <- Result
  1c:  6880        ldr  r0, [r0, #8]

Return
  1e:  4770        bx  lr


von Carl D. (jcw2)


Bewertung
0 lesenswert
nicht lesenswert
pegel schrieb:
> Bei Z80 war ich auch mal dabei. Ist aber schon ein wenig her.
>
> Carl D. schrieb:
>> Soft-FP-Code
>
> Das soll eben nicht passieren.

Ich hab gerade mal mit eclipse gnumcu ein STM32F103 Projekt aufgesetzt,
bei dem ich ein .S Datei mit sert mal "fadd" code aufsetze, dann 
übersetzt der GCC zwar (natürlich, den M3 hat keine FPU) FP-Additionen 
in FP-Lib-Aufrufe, aber die werden eben mit der .S Datei gelinkt und 
dann nicht mehr in der sonst zuständigen Lib gesucht.
Funktioniert bestens.

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich denke das Prinzip der FPU beim APM32F103 ist jetzt klar.

Dank an die Beteiligten.

Bei mir kommt als nächstes das Experiment am lebenden Objekt.

von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
pegel schrieb:
> Ich würde warten bis das Teil da ist und dann den Debugger die Arbeit
> erledigen lassen.
> Dann brauche ich nur die Register und Inhalte der Speicheradressen
> beobachten.
>
> Es kann aber auch nicht schaden, wenn man schon etwas vorab versteht.

Schön das ich für Inspiration sorgen konnte.

Wenn sich in Deiner Arbeitsumgebung Code mit Benutzung der Library 
kompilieren lässt, wäre es noch interessanter die entstehende .elf zu 
disassemblieren. Dann gibt es eine richtig schöne dokumentierte Ausgabe.

von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
Mw E. schrieb:
> Ich bin mal so nett und erfülle deinen Wunsch:
>
>   18:  d0f9        beq.n  e <sc_math_sin+0xe>
>   branch equal, also wenn busybit == 0, dann nach 0xe springen
>   (Pollschleife bis die FPU fertig ist)
>
> Der schiebt da öfter sinnlos Register durch die Gegend.
> auch die Basiadresse wird öfter geladen.
> Da hat wohl wer nicht mit -02 kompiliert.

Wie es ausschaut unterstützt die Library nicht die Nutzung des 
Interrupt.
So wäre ohnehin eine eigene Library notwendig, wenn der gesamte 
Funktionsumfang genutzt werden soll.

Die Denke mit der "geheimen Library" und der Ignoranz der Anfrage von 
Details zur FPU ist absolut nicht nachvollziehbar ...

von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
Carl D. schrieb:
> Ich hab gerade mal mit eclipse gnumcu ein STM32F103 Projekt aufgesetzt,
> bei dem ich ein .S Datei mit sert mal "fadd" code aufsetze, dann
> übersetzt der GCC zwar (natürlich, den M3 hat keine FPU) FP-Additionen
> in FP-Lib-Aufrufe, aber die werden eben mit der .S Datei gelinkt und
> dann nicht mehr in der sonst zuständigen Lib gesucht.
> Funktioniert bestens.

Wäre es bitte möglich dies etwas besser zu erklären?

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
0 lesenswert
nicht lesenswert
Karsten W. schrieb:
> Wie es ausschaut unterstützt die Library nicht die Nutzung des
> Interrupt.

Es wurden doch nichtmal IRQ setzen Register gefunden?
Außerdem muss es doch blockierend sein wenn das als Soft FP Ersatz 
reingelinkt werden soll.
Die Funktionen müssen blockieren bis das Ergebnis bereit steht.

von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
Es sind aber zumindest zusätzliche Interrupts in der apm32f10x.h 
definiert:
#ifdef APM32F10X_LD
  ADC1_2_IRQn                 = 18,     /*!< ADC1 and ADC2 global Interrupt                       */
  USB_HP_CAN1_TX_IRQn         = 19,     /*!< USB Device High Priority or CAN1 TX Interrupts       */
  USB_LP_CAN1_RX0_IRQn        = 20,     /*!< USB Device Low Priority or CAN1 RX0 Interrupts       */
  CAN1_RX1_IRQn               = 21,     /*!< CAN1 RX1 Interrupt                                   */
  CAN1_SCE_IRQn               = 22,     /*!< CAN1 SCE Interrupt                                   */
  EINT9_5_IRQn                = 23,     /*!< External Line[9:5] Interrupts                        */
  TMR1_BRK_IRQn               = 24,     /*!< TMR1 Break Interrupt                                 */
  TMR1_UP_IRQn                = 25,     /*!< TMR1 Update Interrupt                                */
  TMR1_TRG_COM_IRQn           = 26,     /*!< TMR1 Trigger and Commutation Interrupt               */
  TMR1_CC_IRQn                = 27,     /*!< TMR1 Capture Compare Interrupt                       */
  TMR2_IRQn                   = 28,     /*!< TMR2 global Interrupt                                */
  TMR3_IRQn                   = 29,     /*!< TMR3 global Interrupt                                */
  I2C1_EV_IRQn                = 31,     /*!< I2C1 Event Interrupt                                 */
  I2C1_ER_IRQn                = 32,     /*!< I2C1 Error Interrupt                                 */
  SPI1_IRQn                   = 35,     /*!< SPI1 global Interrupt                                */
  USART1_IRQn                 = 37,     /*!< USART1 global Interrupt                              */
  USART2_IRQn                 = 38,     /*!< USART2 global Interrupt                              */
  EINT15_10_IRQn              = 40,     /*!< External Line[15:10] Interrupts                      */
  RTCAlarm_IRQn               = 41,     /*!< RTC Alarm through EINT Line Interrupt                */
  USBWakeUp_IRQn              = 42,     /*!< USB Device WakeUp from suspend through EINT Line Interrupt */    
  FPU_IRQn            = 43,    /*!< FPU Global Interrupt                   */ 
  QSPI_IRQn            = 44,    /*!< QSPI Global Interrupt                   */
#endif /* APM32F10X_LD */  

: Bearbeitet durch User
von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Karsten W. schrieb:
> Wenn sich in Deiner Arbeitsumgebung Code mit Benutzung der Library
> kompilieren lässt, wäre es noch interessanter die entstehende .elf zu
> disassemblieren. Dann gibt es eine richtig schöne dokumentierte Ausgabe.

Habe ich in CubeIDE gemacht.
Der Code ist der Gleiche wie in der sc_math.lib, nur mit angepassten 
Adressen.

Ich konnte sogar Schrittweise auf dem BluePill debuggen bis er versucht 
auf die Adresse 0x40024000 zuzugreifen. Dann kommt ein Hardfault.

Im BluePill scheint irgend etwas zu fehlen. ;)

Übrigens habe ich dabei auch Höhere Takte probiert.
Bis 104MHz kein Problem. Am MCO saubere 52MHz.
Bei 112MHz wird das PLL zittrig, aber ein Blinky läuft immer noch.

von 2⁵ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
pegel schrieb:
> Ich konnte sogar Schrittweise auf dem BluePill debuggen bis er versucht
> auf die Adresse 0x40024000 zuzugreifen. Dann kommt ein Hardfault.
> Im BluePill scheint irgend etwas zu fehlen. ;)

Hm... verstehe ich das jetzt richtig? Du hast ein "Fake"-BluePill mit 
APM µC? Und da geht die FPU nicht? Oder versuchst du, den Code auf einem 
"normalen" STM32F103 BluePill auszuführen?

Was mich etwas nachdenklich macht: Beim Cortex-M4 brauchen die Basis 
Floating-Point-Befehle (vadd, vsub, vmul usw.) ja nur einen Taktzyklus 
(wenn die Pipeline störungsfrei läuft). Beim APM dauern die ja ein 
Vielfaches. ABER: Die komplexen Funktionen (sin, cos, atan usw.) könnten 
hier schneller sein, da diese die M4 Hardware ja nicht bietet. Wäre sehr 
nett, wenn jemand, der (bald) einen APM32F103 hat, hier mal Benchmarks 
machen könnte.

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
2⁵ schrieb:
> Oder versuchst du, den Code auf einem
> "normalen" STM32F103 BluePill auszuführen?

Genau. Mangels APM32F103 habe ich z.Z. keine andere Möglichkeit.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
0 lesenswert
nicht lesenswert
Karsten W. schrieb:
> Es sind aber zumindest zusätzliche Interrupts in der apm32f10x.h
> definiert:

Stimmt, hab ich schonwieder verdrängt.
Das könnte dann aber kein "bin fertig" IRQ sein, sondern wie bei der 
"echten" ARM FPU ein Handler für faults.
Also wenn einmal NaN o.ä. rauskommt.

... Wenn man nur eine Doku hätte ;)

von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
Mw E. schrieb:
> Stimmt, hab ich schonwieder verdrängt.
> Das könnte dann aber kein "bin fertig" IRQ sein, sondern wie bei der
> "echten" ARM FPU ein Handler für faults.
> Also wenn einmal NaN o.ä. rauskommt.
>
> ... Wenn man nur eine Doku hätte ;)

Es wird offensichtlich zwischen "Global" und "Error" Interrupt 
unterschieden.
Da die zusätzlichen Interrupts vom Typ "Global" sind, könnte man 
vermuten das es ein Register gibt welches man auslesen muß, um den Grund 
für den Interrupt herauszufinden?

Wie wird das bei den anderen bekannten "Global" Interrupts gehandhabt?

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
0 lesenswert
nicht lesenswert
In deiner Auflistung sehe ich jetzt nur den globalen?
Die STM32, die ich bisher benutzt habe, hatten auch nur einen globalen 
FPU IRQ.

Der Grund könnte dann im Statusregister stehen.
Mit Statusbits wie:
res Nan
div0
overflow
underflow (zwischen 0 und der kleinsten Zahl gibts nämlich ne Lücke ;) )
Rundungsfehler

Hier ab Seite 14, Kapitel 3.2 wirds erklärt:
https://www.st.com/content/ccc/resource/technical/document/application_note/10/6b/dc/ea/5b/6e/47/46/DM00047230.pdf/files/DM00047230.pdf/jcr:content/translations/en.DM00047230.pdf

Der IRQ ist im Original immer aktiv und kann nur durch den NVIC 
blockiert werden.
Daher mal mit den angekommenen µCs ein paar illegale Operationen rechnen 
und gucken ob der IRQ feuert.
Im IRQ kann man sich dann mal das Statusregister angucken ob da dann 
entsprechend Bits gesetzt sind.

von Carl D. (jcw2)


Bewertung
0 lesenswert
nicht lesenswert
Karsten W. schrieb:
> Carl D. schrieb:
>> Ich hab gerade mal mit eclipse gnumcu ein STM32F103 Projekt aufgesetzt,
>> bei dem ich ein .S Datei mit sert mal "fadd" code aufsetze, dann
>> übersetzt der GCC zwar (natürlich, den M3 hat keine FPU) FP-Additionen
>> in FP-Lib-Aufrufe, aber die werden eben mit der .S Datei gelinkt und
>> dann nicht mehr in der sonst zuständigen Lib gesucht.
>> Funktioniert bestens.
>
> Wäre es bitte möglich dies etwas besser zu erklären?

Ganz einfach, es gibt eine Liste von Funktionen (alle beginnen mit __), 
die GCC aufruft, wenn er FP-Arithmetik ohne HW-Support übersetzt. Diese 
werden, falls nicht anderweitig gefunden, aus den Standard-Bibliothek 
verwendet. Dieses anderweitig kann man eben auch selber 
implementieren. Dabei wird dann nicht eine echte FP-Software-Engine 
benutzt, sondern nur die non-Standard-FPU gefüttert wird.

https://gcc.gnu.org/onlinedocs/gccint/Soft-float-library-routines.html

Edit:
Wobei es auch noch ARM-spezifisches zu geben scheint:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20140811/231209.html

: Bearbeitet durch User
von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
Zur Freude aller deutschen Händler und Feinde des Direktimports läßt 
sich feststellen, daß der Zoll scheinbar seine Tätigkeit nahezu 
eingestellt hat.

Zusätzlich funktioniert ein internationales Tracking bei der Deutschen 
Post nicht mehr.
Alles verschwindet in einem großen schwarzen Loch, sobald es hier 
angekommen ist ...
04.04.2020 08:52
Accepted From Sender

05.04.2020 11:52
Send Item Abroad (export)
Guangzhou

05.04.2020 11:53
Send Item Abroad (export)
Guangzhou

07.04.2020 14:51
Send Item Abroad (export)
Guangzhou

07.04.2020 16:16
Send Item Abroad (export)
Guangzhou
Germany
Deutsche Post AG: LE731309808CN

LE731309808CN   Es konnten keine Informationen zur Sendung gefunden werden.


Tracking bei Aliexpress:
2020.05.03 18:36 (GMT-7): Arrived at destination country
2020.05.03 18:36 (GMT-7): Accepted by Last Mile Carrier
2020.04.22 23:10 (GMT-7): Departed country of origin
2020.04.08 05:45 (GMT-7): Departed country of origin
2020.04.04 08:52 (GMT-7): Shipment accepted by airline
2020.04.04 08:52 (GMT-7): Shipment left country of origin warehouse
2020.04.04 08:52 (GMT-7): Shipment at country of origin warehouse
2020.04.04 08:43 (GMT-7): Shipment dispatched
2020.04.02 17:13 (GMT-7): Waiting for pick up

Warum haben die hier andere Informationen?

: Bearbeitet durch User
von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
Der letzte "Post" hat wohl bei der Post geholfen! ;-)
Heute ist die Sendung eingetroffen.

Alle Interessenten für ein "Muster" bitte noch einmal per PN melden, 
dann können wir die Details klären.
Bitte die Adresse nicht vergessen.

Ergebnisse für erste Tests werden folgen, sobald Zeit dafür vorhanden 
ist ...

: Bearbeitet durch User
von Karsten W. (lsmod)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier sind schon Mal ein paar Bilder von der Black Pill.

Wenn die Stiftleisten eingelötet sind können erste Tests durchgeführt 
werden.

Falls jemand ein Testprogramm hat (ideal mit Hex oder Bin), kann es 
gerne geflasht werden und die Ausgabe (z.B. auf einer UART) wird hier 
gepostet.

: Bearbeitet durch User
von pegel (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Also, wenn wir von einem STM32F103CB ausgehen, habe ich ein erweitertes 
Blinky zu bieten.

Die LED an PC13 blinkt im Sekunden Takt.

Am TX des USART1(PA9) und USART2(PA2) werden DWT Zyklen für 3 Aktionen 
ausgegeben:

- LED Toggle
- PA1 BSRR und BRR
- __NOP()

Das Ganze dient als Vorbereitung für die FPU sin() Zyklenmessung.
Ist in HAL, ohne irgend eine Optimierung.

Erst einmal zum testen ob es überhaupt läuft.

von Bernd N. (_bn_)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Karsten,

Hast ne PN von mir. Das Programm im Anhang sollte ADC Channel 1 auf die 
USB Schnittstelle ausgeben. Ausgabe der Spannung ist in Volt, Baudrate 
im Terminal ist beliebig. Probiers mal aus.

von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
pegel schrieb:

Es ist im neuen Zustand bereits ein Blink-Programm geflasht.
Das ist dann wohl der Test der durchgeführt wird, um den "QC passed" 
Aufkleber zu verleihen. ;-)

Die erste Überraschung ist, daß ein programmieren mit dem ST-Link nicht 
funktioniert.
$ st-flash write 00-Blinky.bin 0x8000000
st-flash 1.6.0-31-gf5d0454-dirty
2020-05-08T10:52:44 INFO common.c: Loading device parameters....
2020-05-08T10:52:44 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2020-05-08T10:52:44 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes
2020-05-08T10:52:44 INFO common.c: Attempting to write 9404 (0x24bc) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08002400 erased
2020-05-08T10:52:44 INFO common.c: Finished erasing 10 pages of 1024 (0x400) bytes
2020-05-08T10:52:44 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2020-05-08T10:52:44 INFO flash_loader.c: Successfully loaded flash loader in sram
2020-05-08T10:52:48 ERROR flash_loader.c: flash loader run error
2020-05-08T10:52:48 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1
stlink_fwrite_flash() == -1

Es funktioniert allerdings die Programmierung über die UART.
Danach gibt Dein Testprogramm folgendes aus:
Zyklen fuer ein LED Toggle: 47
Zyklen fuer ein BSRR/BRR an PA1: 18
Zyklen fuer ein __NOP(): 3

Weitere Details unter 
Beitrag "Re: STM32F103C8T6 - Fälschung von ST bestätigt"

@Bernd: Das andere Binary teste ich später ...

: Bearbeitet durch User
von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
Bernd N. schrieb:
> Das Programm im Anhang sollte ADC Channel 1 auf die
> USB Schnittstelle ausgeben. Ausgabe der Spannung ist in Volt, Baudrate
> im Terminal ist beliebig. Probiers mal aus.

Die USB-Schnittstelle initialisiert schlecht, was aber daran liegt, das 
(gemäß Schaltplan) D+ mit einem 4.7K Pullup gegen +5V geht!
Hier hat RobotDyn wie die anderen versagt!

Nach einigen Versuchen hat es dann doch geklappt.
Bei 3.3V werden 2.995V ausgegeben.
Ein Multimeter mißt 3.32 V.

Das blinken der blauen LED funktioniert bei beiden Programmen.

: Bearbeitet durch User
von Uwe Bonnes (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Karsten W. schrieb:
> Hier hat RobotDyn wie die anderen versagt!

Bug for bug compatibility!

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jetzt wollte ich die FPU zum laufen bewegen, habe es aber noch nicht 
geschafft.

Habe erst einmal alles in die stm32 Dateien eingefügt, Register, 
Interrupts usw. es will aber irgendwie noch nicht.

Deswegen habe ich erst mal alles wieder verworfen und die Minimal 
Version probiert.

Wie im APM FPU Beispiel initialisiert:
  // FPU
  volatile uint32_t *AHBCLKEN    = (uint32_t *)0x40021014;/* [3..3] FPU clock enable */
  volatile uint32_t *FPU_CFGR    = (uint32_t *)0x40021004; /* [27..27] FPUDIV */

  *AHBCLKEN = *AHBCLKEN  | (1<<3);
  while ( (*AHBCLKEN & (1<<3)) == 0 ){};

  *FPU_CFGR = *FPU_CFGR | (1<<27);
  while ( (*FPU_CFGR  & (1<<27)) == 0 ){};

/*
  volatile uint32_t *FPU_Opcode   = (uint32_t  *)0x40024000;
  *FPU_Opcode = (uint32_t)0x09;
*/

  x=0.1f;
  y=sc_math_acos(x);


Laut STM32F103 Ref Man ist Bit 3 vom AHBCLKEN Reserviert, ist beim APM 
das FPU_Clock Enable, kann also passen.

Das CFG Register an Adresse 0x40021004 unterscheidet sich allerdings.
Beim APM32 soll Bit 27 FPUDIV sein, beim STM32 ist das aber Bit 3 vom 
MCO Register.

Im Gegensatz zu STM32, wo ein Hardfault erfolgt wenn man versucht auf 
die Adresse 0x40024000 zu schreiben, funktioniert das beim APM32.
Er springt auch in eine beliebige Funktion aus der sc_math Lib, hängt 
dann aber in der Schleife der Abfrage des Statusbit. Sprich, es kommt 
kein Ergebnis der Hardware FPU zustande.

Irgendwas läuft noch falsch. Jemand eine Idee?

von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
pegel schrieb:

> Irgendwas läuft noch falsch. Jemand eine Idee?

Vielleicht wird nur behauptet das eine FPU vorhanden ist? :-))

Auf jeden Fall bist Du mit den Forschungen schon recht weit gekommen!

: Bearbeitet durch User
von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Karsten W. schrieb:
> Vielleicht wird nur behauptet das eine FPU vorhanden ist? :-))

Ist böse, aber die Idee kam mir auch schon. ;)

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Außer Klagen, das die FPU beim APM32 nicht dokumentiert ist, habe ich 
nichts weiter dazu gefunden.

Ein kleines Beispiel wäre prima, bin mir aber nicht sicher, ob überhaupt 
schon einmal jemand die FPU zum laufen gebracht hat.

von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
Ist es möglich das tolle Beispiel aus der SDK zu kompilieren?

/APM32F103_SDK_v1.0.0/APM32F10x_StdPeriph_Lib_V1.0.0/projects/FPU/Arithm 
etic/src/main.c

Es wäre nicht unbedingt überraschend, wenn selbst dieses nicht 
funktioniert ...

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
pegel schrieb:
> Habe erst einmal alles in die stm32 Dateien eingefügt, Register,
> Interrupts usw. es will aber irgendwie noch nicht.

Gut dass wir nun ganz genau wissen, was du gemacht hast ..... wohl eher 
nicht. Schade.

> 0x40021014
> (1<<3)

I bah! Für einen Q&D test Ok, aber das sollte sich bitte kein Neuling 
abgucken.

In den CMSIS Dateien stehen (hoffentlich) alle Konstanten drin, die man 
braucht. Nur diese sollte man verwenden und ggf. verknüpfen. Ich hoffe 
nur, dass das nicht dein normaler Programmierstil ist.

: Bearbeitet durch User
von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Gut dass wir nun ganz genau wissen, was du gemacht hast ..... wohl eher
> nicht. Schade.

Das war leider zu viel um es einfach zu beschreiben.

Stefan ⛄ F. schrieb:
> In den CMSIS Dateien stehen (hoffentlich) alle Konstanten drin, die man
> braucht.

Eben leider nicht für die FPU, deshalb die Experimente.
Orientiert habe ich mich dabei an:

Carl D. schrieb:
> Ok, 32-Bit-Float,
> 5 32-Bit-Register:
> 0: Opcode
> 1: Status,  Bit0: Busy
> 2: Result
> 3: Op1
> 4: Op2

von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> I bah! Für einen Q&D test Ok, aber das sollte sich bitte kein Neuling
> abgucken.

Kritisieren ist immer einfach.

Vorbildliche konkrete Vorschläge zu posten aus denen man lernen kann, 
ist schon schwieriger. ;-)

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
pegel schrieb:
> Eben leider nicht für die FPU, deshalb die Experimente.

Ja verstehe ich doch. Ich wollte nur drauf hinweisen, damit sich das 
keiner abguckt.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Karsten W. schrieb:
> Vorbildliche konkrete Vorschläge zu posten aus denen man lernen kann,
> ist schon schwieriger. ;-)

Habe ich doch. Normalerweise soll man die Konstanten aus den CMSIS 
Dateien verwenden, das schrieb ich oben direkt im nächsten Satz. Hast du 
den nicht gelesen? (lieber schnell zurück schießen, so sind wir 
Menschen)

Dazu kommt: Ich habe dazu sogar eine recht umfangreiche Webseite mit 
Beispielen veröffentlicht, die man kaum übersehen kann, wenn man nach 
"STM32 Anleitung" sucht.

: Bearbeitet durch User
von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Ich habe dazu sogar eine recht umfangreiche Webseite mit
> Beispielen veröffentlicht

Wenn wir die FPU zum laufen gebracht haben, darfst Du gern alles hübsch 
verpacken. ;)

von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Habe ich doch. Normalerweise soll man die Konstanten aus den CMSIS
> Dateien verwenden, das schrieb ich oben direkt im nächsten Satz. Hast du
> den nicht gelesen? (lieber schnell zurück schießen, so sind wir
> Menschen)

Und wenn man nun eine andere Entwicklungs-Umgebung verwendet, wie z.B. 
STM32Duino?

> Dazu kommt: Ich habe dazu sogar eine recht umfangreiche Webseite mit
> Beispielen veröffentlicht, die man kaum übersehen kann, wenn man nach
> "STM32 Anleitung" sucht.

Meinst Du 
https://www.mikrocontroller.net/articles/STM32_f%C3%BCr_Einsteiger
Für einen Anfänger sind dort keine konkreten Beispiele für dieses 
Problem hier zu finden.
Aber es ist schön das Du diese Seite geschrieben hast - Danke!

Die direkte Ansteuerung der Register läßt sich jedoch übernehmen ...

Dies ist hier doch "Hardware-Hacking" und keine ideale Programmierung 
oder?

: Bearbeitet durch User
von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
Ist Bit3 das richtige für FPU Clk enable? Im CSMSIS file sieht das so 
aus:
  union 
  {
    __IOM uint32_t CFG;                       
  
    struct 
    {
      __IOM uint32_t SCSEL    : 2;           
      __IM  uint32_t SCS          : 2;           
      __IOM uint32_t AHBDIV       : 4;           
      __IOM uint32_t APB1DIV      : 3;           
      __IOM uint32_t APB2DIV      : 3;           
      __IOM uint32_t ADCDIV       : 2;           
      __IOM uint32_t PLLSEL       : 1;           
      __IOM uint32_t PLLXTDIV     : 1;           
      __IOM uint32_t PLLMF        : 4;           
      __IOM uint32_t USBDIV     : 1;           
      __IM  uint32_t RESERVED1    : 1;
      __IOM uint32_t COC          : 3;           
      __IOM uint32_t FPUDIV    : 1;  
      __IM  uint32_t RESERVED2    : 4;
    } CFG_B;
  } ;

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Johannes S. schrieb:
> FPU Clk enable

Ist im anderen Register. Aus der apm32f10x.h:
  union {
    __IOM uint32_t AHBCLKEN;                    /*!< (@ 0x00000014) AHB clock enable register (RCM_AHBCLKEN)                   */
    
    struct {
      __IOM uint32_t DMA1CLKE   : 1;            /*!< [0..0] DMA1 clock enable                                                  */
      __IOM uint32_t DMA2CLKE   : 1;            /*!< [1..1] DMA2 clock enable                                                  */
      __IOM uint32_t SRAMCLKE   : 1;            /*!< [2..2] SRAM interface clock enable                                        */
      __IOM uint32_t FPUCLKE    : 1;            /*!< [3..3] FLITF clock enable                                                 */
      __IOM uint32_t FMCCLKE    : 1;            /*!< [4..4] CRC clock enable                                                   */
      __IOM uint32_t QSPICLKE   : 1;            /*!< [5..5] QSPICLKE                                                           */
      __IOM uint32_t CRCCLKE    : 1;            /*!< [6..6] CRCCLKE                                                            */
      __IM  uint32_t            : 1;
      __IOM uint32_t EMMCCLKEN  : 1;            /*!< [8..8] FSMC clock enable                                                  */
      __IM  uint32_t            : 1;
      __IOM uint32_t SDIOCLKE   : 1;            /*!< [10..10] SDIO clock enable                                                */
    } AHBCLKEN_B;
  } ;

Die Kommentare passen leider auch nicht so genau.

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
In der main.c vom APM32 FPU Beispiel, wird die FPU so initialisiert:
    RCM_EnableAHBPeriphClock(RCM_AHB_PERIPH_FPU);
    RCM->CFG |= 0x08000000;
Das sollte meinem Init entsprechen:
  volatile uint32_t *AHBCLKEN    = (uint32_t *)0x40021014;/* [3..3] FPU clock enable */
  volatile uint32_t *FPU_CFGR    = (uint32_t *)0x40021004; /* [27..27] FPUDIV */

  *AHBCLKEN = *AHBCLKEN  | (1<<3);
  while ( (*AHBCLKEN & (1<<3)) == 0 ){};

  *FPU_CFGR = *FPU_CFGR | (1<<27);
  while ( (*FPU_CFGR  & (1<<27)) == 0 ){};
Durch das while und auch durch Debug kann ich das setzen der Bits 3 bzw. 
27 bestätigen.

von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
Es ist nicht zu erkennen das noch was fehlt ...

Es kann nur noch sein das in der generellen Initialisierung irgendetwas 
getan wird, was sich noch nicht offenbart hat?

Oder aber es ist einfach nur ein nicht funktionsfähiges Beispiel.

Oder man braucht einen spezifischen chinesischen Wandkalender? :-)

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich werde später noch mal das gesamte sin array Zeugs aus dem Beispiel 
probieren.
Vielleicht fehlt irgend ein Nachbar Byte das gebraucht wird.

Jetzt ist erst mal Pause.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Karsten W. schrieb:
> Und wenn man nun eine andere Entwicklungs-Umgebung verwendet, wie z.B.
> STM32Duino?

STM32Duino basiert auf der Cube HAL, die wiederum auf CMSIS basiert. Da 
hast du daher alle Konstanten ebenso zur Verfügung.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Karsten W. schrieb:
> Meinst Du
> https://www.mikrocontroller.net/articles/STM32_f%C3%BCr_Einsteiger
> Für einen Anfänger sind dort keine konkreten Beispiele für dieses
> Problem hier zu finden.
> Aber es ist schön das Du diese Seite geschrieben hast - Danke!

Nein diese Anleitung meine ich nicht. An der war ich auch nicht 
beteiligt, außer ein paar kleine unwesentliche Aktualisierungen. Gehe 
mal da hin: http://stefanfrings.de/stm32/index.html

> Dies ist hier doch "Hardware-Hacking" und
> keine ideale Programmierung oder?

Ja, falls du mit "das hier" die Experimente mit der chinesischen 
FPU-Komponente meinst.

: Bearbeitet durch User
von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Gehe mal da hin: http://stefanfrings.de/stm32/index.html

Danke für die Hinweise.
Diese Seite hat für einen ersten Einblick bereits gute Dienste 
geleistet.

> Ja, falls du mit "das hier" die Experimente mit der chinesischen
> FPU-Komponente meinst.

Man kann hier doch sehr schön erkennen, wie unübersichtlich alleine 
schon die korrekte Initialisierung einer solchen MCU ist.
Von den ganzen Varianten dieser MCU's Mal ganz abgesehen ...

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Karsten W. schrieb:
> wie unübersichtlich alleine
> schon die korrekte Initialisierung einer solchen MCU ist

Verglichen mit den bekannten meisten 8bit Controllern: ja auf jeden 
Fall.

Wobei mein erster Kontakt mit der Takt-Konfiguration eines Xmega128D3 
auch einige graue Haare wachsen lies. Versuche mal heraus zu finden, wie 
man dort den relativ ungenauen 2 MHz R/C Oszillator mit PLL auf 32 MHz 
einstellt und so mit dem besseren 32 kHz R/C Oszillator synchronisiert, 
dass damit UART Kommunikation zuverlässig funktioniert.

Ich hab's hinbekommen aber seit dem sind die Xmega für mich ziemlich 
unattraktiv geworden. Da nehme ich lieber die (doch nicht 
komplizierteren) STM32, die nur ein Bruchteil davon kosten und als 
Hobbyelektroniker erheblich leichter in Form von Modulen beschaffbar 
sind.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
was soll jetzt wieder die Ablenkung mit STM und XMegas bringen? Es geht 
doch eindeutig um die Nutzung der APM FPU. Und wenn man Konstanten als 
Wert richtig angibt muss es genauso wie mit einem Literal funktionieren.
Und da es ein APM ist braucht man das APM CMSIS file, das hat pegel 
benutzt. Ich habe die Konstanten auch verglichen und halte die auch für 
richtig. Und kompliziert ist die Initialisierung der FPU auch nicht, 
Power und Clock einschalten wie bei allen Peripherials.
Kann das Problem daran liegen das der Keil Compiler bei Aufrufen 
gegenüber der gcc etwas anders macht? Das .lib file ist ja von und für 
Keil.

von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
Jeder Thread gerät Mal auf Abwege ... :-)

Die Library wurde von pegel doch eingebunden, also sollte auch der darin 
enthaltene Code ausgeführt werden oder?

Es ist eine gute Frage was der Keil'er speziell veranstalten mag.
Wenn man in die SDK schaut gibt es die 4.9 MB große Datei
APM32F103/APM32F103_SDK_v1.0.0/Package/APEXMIC.APM32F1xx_DFP.1.0.0.pack

Wozu ist die gut?

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
da sind üblicherweise Device und Registerbeschreibungen die Debugger 
verwenden.
Und der Thread wurde doch schon genug durch irgendwelche 
Marktwirtschaftsdiskussionen verschandelt.

von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
Das stimmt. :-(

Es wäre hilfreich wenn jemand der über den Keil Compiler verfügt das 
Beispiel für die FPU aus der SDK kompilieren würde ...
https://www.apexmic.com/uploads/tool/APM32F103_SDK_V1.0.0.rar

: Bearbeitet durch User
von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
Karsten W. schrieb:
> Die Library wurde von pegel doch eingebunden, also sollte auch der darin
> enthaltene Code ausgeführt werden oder?

ja, er schrieb ja das er mit dem Debugger bis zum Warten auf das FPU 
Result gekommen ist. Das hört sich eigentlich gut an, aber die 
Initialisierung sieht auch nicht falsch aus, also muss man in grösseren 
Kreisen suchen.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
aber das hier ist interessant, ist da ein APM32E oder F drauf? Bei F 
wirds wohl nix wenn das hier richtig ist.
https://github.com/RobotDynOfficial/Documentation/issues/1

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Dem Foto nach ist es wohl ein F ohne FPU - wie schade.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
eher ärgerlich - weil das Board falsch beworben wird.

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wie?
Was muss ich da lesen?

Ich habe eindeutig ein 32 F.

Wenn ich die FPU erst noch selbst in Silizium ätzen und Anflanschen 
muss, wird mir der Aufwand dann doch zu groß.

In den links habe ich nur das mit dem QSPI bei der E Variante 
gefunden, wo genau steht das mit der FPU?

Irgendwie habe ich jetzt einen Motivationsknick. :(

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das mit der Übertaktung beim normalen Bluepill hatte ich oben schon mal 
getestet:

pegel schrieb:
> Übrigens habe ich dabei auch Höhere Takte probiert.
> Bis 104MHz kein Problem. Am MCO saubere 52MHz.
> Bei 112MHz wird das PLL zittrig, aber ein Blinky läuft immer noch.

USB wird allerdings schwierig, da der USB Vorteiler nur 1 oder 1,5 sein 
kann. Soll beim APM auch noch 2 geben.

von Karsten W. (lsmod)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Johannes S. schrieb:
> aber das hier ist interessant, ist da ein APM32E oder F drauf? Bei F
> wirds wohl nix wenn das hier richtig ist.
> https://github.com/RobotDynOfficial/Documentation/issues/1

Wir haben die F-Variante.

Aber wenn man das Dokument auf S. 10 betrachtet, sollte diese MCU 
dennoch eine FPU haben.
https://www.apexmic.com/uploads/tool/APM32F103x4x6x8xB%20Data%20Sheet%20V1.0.5.pdf

Wenn sich diese nicht ansteuern läßt, ist sie dennoch nur eine 
Wunsch-FPU. :-(

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Da steht auch, dass wir ein QSPI haben.

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Zitat:
"QSPI was added to APM32E series, which supports Standard SPI mode and 
Quad SPI mode;"

Beitrag #6259262 wurde vom Autor gelöscht.
von Karsten W. (lsmod)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ein Wunsch-QSPI halt. ;-)

Dies steht alles ebenso in der model list auf der Produkt-Seite
https://www.apexmic.com/en/newproduct/apm2/16


Aber hier ist es vollkommen anders dargestellt!
https://www.apexmic.com/uploads/tool/MCU%20Selection%20Guide1554692496340.pdf

Hier haben tatsächlich nur die E=nhanced Modelle eine FPU !!!

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Geben wir es zu: vom China Mann aufs Kreuz gelegt.

Nehmen wir es als normales Bluepill mir echten 128K.

von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
Zugegeben - man könnte auch sagen RobotDyn wurde genauso in die Irre 
geführt.
Mal schauen was RobotDyn darauf antwortet ...

Es ist ja nicht so das diese unbrauchbar sind - aber im Sinne dieses 
Threads eine absolute Enttäuschung!

: Bearbeitet durch User
von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Vielleicht sollte man sich mal ansehen, wie möglichst schnell und 
Platzsparend die trigonometrischen Funktionen in der FPU eines 
BlackPill(F401) untergebracht werden können.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
ändert sich denn etwas an der Stromaufnahme wenn FPU power und clock 
aktiviert wurden?

Die Datenblätter sind ja sehr wiedersprüchlich, auch die Website ist 
gerade schlecht zu erreichen. Zuviele Downloads und die China Firewall 
macht dicht?

von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
Richard K. schrieb:
> Ich habe Bilder des APM32-Dies gemacht:
>
> https://www.richis-lab.de/STM32_05.htm
>
> Der Chip scheint zumindest zu einem gewissen Teil von SEC-CHIP
> entwickelt worden zu sein.
> Außerdem erinnert das Die entfernt an den CKS32/CS32:
> https://www.richis-lab.de/STM32_03.htm
> Diese Testpads innerhalb der Logik...

Im nachhinein fällt auf, daß bei einem Vergleich der Bilder eine FPU gar 
nicht vorhanden sein kann.
Da müsste bei dem APM-Dies einfach mehr Logik zu sehen sein.

von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
pegel schrieb:
> Vielleicht sollte man sich mal ansehen, wie möglichst schnell und
> Platzsparend die trigonometrischen Funktionen in der FPU eines
> BlackPill(F401) untergebracht werden können.

Sollte dies nicht bereits Bestandteil des Compilers sein?

Arm Cortex -M4 32-bit RISC core operating at a frequency of up to 84 MHz.
The Cortex®-M4 core features a Floating point unit (FPU) single precision which supports all Arm single-precision data-processing instructions and data types.
It also implements a full set of DSP instructions and a memory protection unit (MPU) which enhances application security.

Die FPU hat wirklich nicht allzuviele Funktionen implementiert:
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0363e/Babbdghg.html


Auf jeden Fall ist dies nicht Thema dieses Threads.

: Bearbeitet durch User
von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Karsten W. schrieb:
> Auf jeden Fall ist dies nicht Thema dieses Threads.

Richtig. Aber als Anregung für Forschungen in der Richtung gedacht.

Wenn man schon mal auf den trigonometrischen Geschmack gekommen ist....

von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
pegel schrieb:
> Wenn man schon mal auf den trigonometrischen Geschmack gekommen ist....

Das stimmt - dann mache doch dafür einen neuen Thread auf.
Du hast doch von den STM32F401CCU6 bereits ein paar erworben oder?

Aber man kann auch unabhängig davon den kompilierten Code vergleichen.

Hier noch als Referenz die Ergebnisse der klassischen Berechnung:
2747 Takte sin(3.14) = -0.00
2577 Takte sin(3.04) = 0.10
2208 Takte sin(2.94) = 0.20
2208 Takte sin(2.84) = 0.30
2208 Takte sin(2.74) = 0.39
2208 Takte sin(2.64) = 0.48
2208 Takte sin(2.54) = 0.56
2208 Takte sin(2.44) = 0.64
2027 Takte sin(2.34) = 0.72
2027 Takte sin(2.24) = 0.78
2027 Takte sin(2.14) = 0.84
2039 Takte sin(2.04) = 0.89
2027 Takte sin(1.94) = 0.93
1825 Takte sin(1.84) = 0.96
1824 Takte sin(1.74) = 0.99
1824 Takte sin(1.64) = 1.00
1824 Takte sin(1.54) = 1.00
1824 Takte sin(1.44) = 0.99
1824 Takte sin(1.34) = 0.97
2027 Takte sin(1.24) = 0.95
2039 Takte sin(1.14) = 0.91
2024 Takte sin(1.04) = 0.86
2024 Takte sin(0.94) = 0.81
2024 Takte sin(0.84) = 0.75
1051 Takte sin(0.74) = 0.68
1051 Takte sin(0.64) = 0.60
1051 Takte sin(0.54) = 0.52
1051 Takte sin(0.44) = 0.43
1051 Takte sin(0.34) = 0.33
1051 Takte sin(0.24) = 0.24
1051 Takte sin(0.14) = 0.14
1051 Takte sin(0.04) = 0.04

: Bearbeitet durch User
von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Karsten W. schrieb:
> Du hast doch von den STM32F401CCU6 bereits ein paar erworben oder?

Ja, die haben leider eine USB-C Buchse.
Sonst hätte ich schon mehr damit gemacht.

Kabel/Adapter für beide Richtungen muss ich noch irgend wann 
mitbestellen.

Eins nach dem Anderen.

von John Doe (Gast)


Bewertung
0 lesenswert
nicht lesenswert
pegel schrieb:
> Karsten W. schrieb:
>> Du hast doch von den STM32F401CCU6 bereits ein paar erworben oder?
>
> Ja, die haben leider eine USB-C Buchse.
> Sonst hätte ich schon mehr damit gemacht.


Ich habe die ähnlichen STM32F411CEU6 hier, da sind die Pins für SW 
rausgeführt. Nutz die doch.
Ich komme leider auch frühestens in einer Woche zum Testen.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
für einen F411 @ 96 MHz (so einen WeAct Blackpill) komme ich für einen 
sin() auf 1,6 µs.
32 Sinüsse berechnet und in Array geschrieben, 51 µs gesamt gemessen. 
Die DWT Zyklenzähler habe ich noch nicht benutzt, muss ich auch mal 
einbauen.
Bei 100 Zyklen pro µs wären das dann etwa 160 Zyklen.

: Bearbeitet durch User
von Karsten W. (lsmod)


Bewertung
0 lesenswert
nicht lesenswert
Johannes S. schrieb:
> Bei 100 Zyklen pro µs wären das dann etwa 160 Zyklen.

Wenn die Performance in diesem Bereich benötigt wird, ist das schon ein 
riesiger Fortschritt.

Der Reiz der APM32 war jedoch eine preiswerte x103 MCU, die als Extra 
u.a. eine FPU, 128 KB Speicher und QSPI bei Bedarf bieten sollte.
Dies wurde nun leider widerlegt.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Karsten W. schrieb:
> Der Reiz der APM32 war jedoch eine preiswerte x103 MCU, die als Extra
> u.a. eine FPU, 128 KB Speicher und QSPI bei Bedarf bieten sollte.

Den Speicher und die FPU bekommt man auch beim STM32F303 zum ungefähr 
gleichen Preis.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
Den Zyklenzähler hatte ich beim F411 auch noch eingebaut, die 1.6 µs 
sind ein Mittelwert, die sin() Berechnung ist Wertabhängig. Ich kam 
dabei auf 70...200 Zyklen bei den Eingangswerten von 0.04 bis 3.14.

Die APM mit Trigonometrie Berechnung in Hardware könnten da noch 
schneller sein. Wenn Apexmic sowas anbietet wird es ja auch Kunden und 
spezielle Anwendungen dafür gegeben haben. Vielleicht die eScooter mit 
BLDC, braucht man da sin/cos für?
Über die E Version findet man auf der Website ja nichts, so richtig 
eindeutig sind die Datenblätter auch nicht. Die ganze Palette die da 
aufgeführt ist sieht eher nach Werbung aus: Wir könnten das bauen wenn 
ihr es in Stückzahlen haben wollt.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.