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.
Wasserkocher schrieb: > Running power consumption: 340mA/MHz > > Donnerwetter! Vermutlich mμkro-Ampere.
:
Bearbeitet durch User
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?
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
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
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 ...
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.
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
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?
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
Also, wenn 3 Stück insgesamt nicht mehr als einen Zehner kosten, wäre ich dabei.
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€.
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
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.
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
Meinst Du das? Da ist nicht viel drauf. Link zur Schaltung unten auf der Seite: https://github.com/mcauser/WEACT_F411CEU6
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!
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
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
/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.
1 | extern float sc_math_sin(float x); |
2 | extern float sc_math_cos(float x); |
3 | extern float sc_math_tan(float x); |
4 | extern float sc_math_asin(float x); |
5 | extern float sc_math_acos(float x); |
6 | extern float sc_math_atan(float x); |
7 | extern float sc_math_atan2(float y, float x); |
8 | |
9 | extern float sc_math_invsqrt(float x); |
10 | extern float sc_math_mac(float x, float y, float z); |
11 | extern float sc_math_sum_N(float* x, unsigned char n); |
12 | extern float sc_math_sub_N(float* x, unsigned char n); |
13 | extern float sc_math_prdct(float* x, unsigned char n); |
14 | extern float sc_math_sumsq(float* x, unsigned char n); |
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.
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.
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
Angehängte Dateien:
-
APM32.png
85 KB
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. :(
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.
pegel schrieb: > Leider nicht, deshalb habe ich "versteckt" geschrieben. Welche unglaublichen Firmengeheimnisse mögen da drinn wohl versteckt sein? :-D
Vermutlich die Hardware Adressen der FPU Register. Lassen sich vielleicht im Debug auf ASM Ebene sogar herausfinden.
pegel schrieb: > Vermutlich die Hardware Adressen der FPU Register. Müssen ja alle im Bereich: 0x40024000 - 0x40024400 liegen.
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...
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...
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.
Naja, solange die IP nicht gestohlen ist, kann man bekannte Schnittstellen legitim nachbauen.
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.
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
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?
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.
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.
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?
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
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
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. ;)
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.
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
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
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.
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.
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
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.
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
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.
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.
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
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).
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... ;)
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
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?
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
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.
@ 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.
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?
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).
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?
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!
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.
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.
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:
1 | 00000000 <sc_math_sin>: |
2 | 0: 4601 mov r1, r0 |
3 | 2: 2009 movs r0, #9 |
4 | 4: 4afe ldr r2, [pc, #1016] ; (400 <__wrap___ltsf2+0x2a>) |
5 | 6: 6010 str r0, [r2, #0] |
6 | 8: 4610 mov r0, r2 |
7 | a: 60c1 str r1, [r0, #12] |
8 | c: bf00 nop |
9 | e: 48fc ldr r0, [pc, #1008] ; (400 <__wrap___ltsf2+0x2a>) |
10 | 10: 6840 ldr r0, [r0, #4] |
11 | 12: f000 0001 and.w r0, r0, #1 |
12 | 16: 2800 cmp r0, #0 |
13 | 18: d0f9 beq.n e <sc_math_sin+0xe> |
14 | 1a: 48f9 ldr r0, [pc, #996] ; (400 <__wrap___ltsf2+0x2a>) |
15 | 1c: 6880 ldr r0, [r0, #8] |
16 | 1e: 4770 bx lr |
Ab:
1 | 400: 40024000 .word 0x40024000 |
befindet sich die FPU Hardware.
Ich bin mal so nett und erfülle deinen Wunsch: Die Funktion ist float sc_math_sin(float value); also r0 = value
1 | 00000000 <sc_math_sin>: |
2 | 0: 4601 mov r1, r0 |
3 | r0 in r1 sichern, also kopieren |
4 | |
5 | 2: 2009 movs r0, #9 |
6 | die Zahl 9 als immediate nach r0 schreiben mit statusflags update (das s) (wozu auch immer) |
7 | |
8 | 4: 4afe ldr r2, [pc, #1016] ; (400 <__wrap___ltsf2+0x2a>) |
9 | einen Wert nach r2 laden |
10 | ARM packt Konstanten gerne in den Code rein, daher ist der Programmcounter hier vorhanden |
11 | pc + 1016 ist die Adresse zum laden, aber ARM ist pipelined, also pc ist schon pc+4! |
12 | adresse: pc (ist 4) + 4 + 1016 = 1024 = 0x400 |
13 | und da liegt die Basiadresse der FPU Register! (=0x40024000) |
14 | -> r2 = Basisadresse der FPU Register |
15 | |
16 | 6: 6010 str r0, [r2, #0] |
17 | jetzt wird die 9 in das erste memory mapped Register der FPU geschrieben |
18 | also der Opcode = 9 für sinus |
19 | |
20 | 8: 4610 mov r0, r2 |
21 | jetzt wird r2 nach r0 kopiert |
22 | |
23 | a: 60c1 str r1, [r0, #12] |
24 | jetzt wird der floatwert in ein memory mapped FPU Register geschrieben |
25 | Weil das 32Bit register sind: 12/4 -> Register 3 -> Op1 der FPU |
26 | |
27 | c: bf00 nop |
28 | 1 Takt nix tun |
29 | |
30 | e: 48fc ldr r0, [pc, #1008] ; (400 <__wrap___ltsf2+0x2a>) |
31 | schonwieder die Basiadresse laden obwohl die immernoch in r2 steht... |
32 | |
33 | 10: 6840 ldr r0, [r0, #4] |
34 | jetzt ein FPU Register laden, das memory mapped FPU Register 1 (Status) |
35 | |
36 | 12: f000 0001 and.w r0, r0, #1 |
37 | verunden mit 1, also das Busy bit angucken |
38 | |
39 | 16: 2800 cmp r0, #0 |
40 | das busy bit mit 0 vergleichen und statusflags setzen |
41 | |
42 | 18: d0f9 beq.n e <sc_math_sin+0xe> |
43 | branch equal, also wenn busybit == 0, dann nach 0xe springen |
44 | (Pollschleife bis die FPU fertig ist) |
45 | |
46 | 1a: 48f9 ldr r0, [pc, #996] ; (400 <__wrap___ltsf2+0x2a>) |
47 | schonwieder die Basiadresse laden obwohl die immernoch in r2 steht... |
48 | |
49 | 1c: 6880 ldr r0, [r0, #8] |
50 | jetzt ein FPU Register laden, das memory mapped FPU Register 1 (Status) |
51 | Weil das 32Bit register sind: 8/4 -> Register 2 -> Result der FPU |
52 | r0 ist laut calling convention das Rückgaberegister |
53 | |
54 | 1e: 4770 bx lr |
55 | branch exchange |
56 | nach LinkRegister springen, das wurde vom caller gesetzt (branch and link) |
57 | 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
Vielen Dank. Ich habe auch ein wenig selbst probiert, das kam dabei raus:
1 | 00000000 <sc_math_sin>: |
2 | |
3 | r1 <- Wert |
4 | 0: 4601 mov r1, r0 |
5 | |
6 | r0 <- 0x00000009 |
7 | 2: 2009 movs r0, #9; sin Opcode |
8 | |
9 | r2 <- [0x40024000]; Inhalt von Adresse 0x40024000 |
10 | 4: 4afe ldr r2, [pc, #1016] ; (400 <__wrap___ltsf2+0x2a>) |
11 | |
12 | r0 -> [0x40024000]; r0 auf Adresse 0x40024000 ablegen (9:sin) |
13 | 6: 6010 str r0, [r2, #0] |
14 | |
15 | r0 <- r2; vorheriger Inhalt von Adresse 0x40024000 |
16 | 8: 4610 mov r0, r2 |
17 | |
18 | r1 -> r0+12; r1 in vorherigem Inhalt von Adresse 0x4002400C (Wert in OP1) |
19 | a: 60c1 str r1, [r0, #12] |
20 | |
21 | c: bf00 nop |
22 | |
23 | r0 <- [0x40024000]; Inhalt von Adresse 0x40024000 |
24 | e: 48fc ldr r0, [pc, #1008] ; (400 <__wrap___ltsf2+0x2a>) |
25 | |
26 | r0 <- [0x40024000+4]; Status Register |
27 | 10: 6840 ldr r0, [r0, #4] |
28 | |
29 | logisch "und" r0,1; Busy? |
30 | 12: f000 0001 and.w r0, r0, #1 |
31 | r0 = 0? |
32 | 16: 2800 cmp r0, #0 |
33 | |
34 | wenn nicht, springe zu e: |
35 | 18: d0f9 beq.n e <sc_math_sin+0xe> |
36 | |
37 | r0 <- [0x40024000] |
38 | 1a: 48f9 ldr r0, [pc, #996] ; (400 <__wrap___ltsf2+0x2a>) |
39 | |
40 | r0 <- Result |
41 | 1c: 6880 ldr r0, [r0, #8] |
42 | |
43 | Return |
44 | 1e: 4770 bx lr |
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.
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.
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.
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 ...
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?
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.
Es sind aber zumindest zusätzliche Interrupts in der apm32f10x.h definiert:
1 | #ifdef APM32F10X_LD
|
2 | ADC1_2_IRQn = 18, /*!< ADC1 and ADC2 global Interrupt */ |
3 | USB_HP_CAN1_TX_IRQn = 19, /*!< USB Device High Priority or CAN1 TX Interrupts */ |
4 | USB_LP_CAN1_RX0_IRQn = 20, /*!< USB Device Low Priority or CAN1 RX0 Interrupts */ |
5 | CAN1_RX1_IRQn = 21, /*!< CAN1 RX1 Interrupt */ |
6 | CAN1_SCE_IRQn = 22, /*!< CAN1 SCE Interrupt */ |
7 | EINT9_5_IRQn = 23, /*!< External Line[9:5] Interrupts */ |
8 | TMR1_BRK_IRQn = 24, /*!< TMR1 Break Interrupt */ |
9 | TMR1_UP_IRQn = 25, /*!< TMR1 Update Interrupt */ |
10 | TMR1_TRG_COM_IRQn = 26, /*!< TMR1 Trigger and Commutation Interrupt */ |
11 | TMR1_CC_IRQn = 27, /*!< TMR1 Capture Compare Interrupt */ |
12 | TMR2_IRQn = 28, /*!< TMR2 global Interrupt */ |
13 | TMR3_IRQn = 29, /*!< TMR3 global Interrupt */ |
14 | I2C1_EV_IRQn = 31, /*!< I2C1 Event Interrupt */ |
15 | I2C1_ER_IRQn = 32, /*!< I2C1 Error Interrupt */ |
16 | SPI1_IRQn = 35, /*!< SPI1 global Interrupt */ |
17 | USART1_IRQn = 37, /*!< USART1 global Interrupt */ |
18 | USART2_IRQn = 38, /*!< USART2 global Interrupt */ |
19 | EINT15_10_IRQn = 40, /*!< External Line[15:10] Interrupts */ |
20 | RTCAlarm_IRQn = 41, /*!< RTC Alarm through EINT Line Interrupt */ |
21 | USBWakeUp_IRQn = 42, /*!< USB Device WakeUp from suspend through EINT Line Interrupt */ |
22 | FPU_IRQn = 43, /*!< FPU Global Interrupt */ |
23 | QSPI_IRQn = 44, /*!< QSPI Global Interrupt */ |
24 | #endif /* APM32F10X_LD */ |
:
Bearbeitet durch User
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.
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.
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.
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 ;)
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?
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.
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
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 ...
1 | 04.04.2020 08:52 |
2 | Accepted From Sender |
3 | |
4 | 05.04.2020 11:52 |
5 | Send Item Abroad (export) |
6 | Guangzhou |
7 | |
8 | 05.04.2020 11:53 |
9 | Send Item Abroad (export) |
10 | Guangzhou |
11 | |
12 | 07.04.2020 14:51 |
13 | Send Item Abroad (export) |
14 | Guangzhou |
15 | |
16 | 07.04.2020 16:16 |
17 | Send Item Abroad (export) |
18 | Guangzhou |
19 | Germany |
20 | Deutsche Post AG: LE731309808CN |
21 | |
22 | LE731309808CN Es konnten keine Informationen zur Sendung gefunden werden. |
Tracking bei Aliexpress:
1 | 2020.05.03 18:36 (GMT-7): Arrived at destination country |
2 | 2020.05.03 18:36 (GMT-7): Accepted by Last Mile Carrier |
3 | 2020.04.22 23:10 (GMT-7): Departed country of origin |
4 | 2020.04.08 05:45 (GMT-7): Departed country of origin |
5 | 2020.04.04 08:52 (GMT-7): Shipment accepted by airline |
6 | 2020.04.04 08:52 (GMT-7): Shipment left country of origin warehouse |
7 | 2020.04.04 08:52 (GMT-7): Shipment at country of origin warehouse |
8 | 2020.04.04 08:43 (GMT-7): Shipment dispatched |
9 | 2020.04.02 17:13 (GMT-7): Waiting for pick up |
Warum haben die hier andere Informationen?
:
Bearbeitet durch User
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
Angehängte Dateien:
-
APM32F103CBT6.mcu.jpg
210 KB -
Oberseite.jpg
230 KB -
Unterseite.jpg
220 KB
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
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.
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.
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.
1 | $ st-flash write 00-Blinky.bin 0x8000000 |
2 | st-flash 1.6.0-31-gf5d0454-dirty |
3 | 2020-05-08T10:52:44 INFO common.c: Loading device parameters.... |
4 | 2020-05-08T10:52:44 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410 |
5 | 2020-05-08T10:52:44 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes |
6 | 2020-05-08T10:52:44 INFO common.c: Attempting to write 9404 (0x24bc) bytes to stm32 address: 134217728 (0x8000000) |
7 | Flash page at addr: 0x08002400 erased |
8 | 2020-05-08T10:52:44 INFO common.c: Finished erasing 10 pages of 1024 (0x400) bytes |
9 | 2020-05-08T10:52:44 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id |
10 | 2020-05-08T10:52:44 INFO flash_loader.c: Successfully loaded flash loader in sram |
11 | 2020-05-08T10:52:48 ERROR flash_loader.c: flash loader run error |
12 | 2020-05-08T10:52:48 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1 |
13 | stlink_fwrite_flash() == -1 |
Es funktioniert allerdings die Programmierung über die UART. Danach gibt Dein Testprogramm folgendes aus:
1 | Zyklen fuer ein LED Toggle: 47 |
2 | Zyklen fuer ein BSRR/BRR an PA1: 18 |
3 | 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
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
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:
1 | // FPU
|
2 | volatile uint32_t *AHBCLKEN = (uint32_t *)0x40021014;/* [3..3] FPU clock enable */ |
3 | volatile uint32_t *FPU_CFGR = (uint32_t *)0x40021004; /* [27..27] FPUDIV */ |
4 | |
5 | *AHBCLKEN = *AHBCLKEN | (1<<3); |
6 | while ( (*AHBCLKEN & (1<<3)) == 0 ){}; |
7 | |
8 | *FPU_CFGR = *FPU_CFGR | (1<<27); |
9 | while ( (*FPU_CFGR & (1<<27)) == 0 ){}; |
10 | |
11 | /*
|
12 | volatile uint32_t *FPU_Opcode = (uint32_t *)0x40024000;
|
13 | *FPU_Opcode = (uint32_t)0x09;
|
14 | */
|
15 | |
16 | x=0.1f; |
17 | 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?
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
Karsten W. schrieb: > Vielleicht wird nur behauptet das eine FPU vorhanden ist? :-)) Ist böse, aber die Idee kam mir auch schon. ;)
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.
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 ...
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.
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
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
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.
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.
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. ;)
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
Ist Bit3 das richtige für FPU Clk enable? Im CSMSIS file sieht das so aus:
1 | union
|
2 | {
|
3 | __IOM uint32_t CFG; |
4 | |
5 | struct
|
6 | {
|
7 | __IOM uint32_t SCSEL : 2; |
8 | __IM uint32_t SCS : 2; |
9 | __IOM uint32_t AHBDIV : 4; |
10 | __IOM uint32_t APB1DIV : 3; |
11 | __IOM uint32_t APB2DIV : 3; |
12 | __IOM uint32_t ADCDIV : 2; |
13 | __IOM uint32_t PLLSEL : 1; |
14 | __IOM uint32_t PLLXTDIV : 1; |
15 | __IOM uint32_t PLLMF : 4; |
16 | __IOM uint32_t USBDIV : 1; |
17 | __IM uint32_t RESERVED1 : 1; |
18 | __IOM uint32_t COC : 3; |
19 | __IOM uint32_t FPUDIV : 1; |
20 | __IM uint32_t RESERVED2 : 4; |
21 | } CFG_B; |
22 | } ; |
Johannes S. schrieb: > FPU Clk enable Ist im anderen Register. Aus der apm32f10x.h:
1 | union { |
2 | __IOM uint32_t AHBCLKEN; /*!< (@ 0x00000014) AHB clock enable register (RCM_AHBCLKEN) */ |
3 | |
4 | struct { |
5 | __IOM uint32_t DMA1CLKE : 1; /*!< [0..0] DMA1 clock enable */ |
6 | __IOM uint32_t DMA2CLKE : 1; /*!< [1..1] DMA2 clock enable */ |
7 | __IOM uint32_t SRAMCLKE : 1; /*!< [2..2] SRAM interface clock enable */ |
8 | __IOM uint32_t FPUCLKE : 1; /*!< [3..3] FLITF clock enable */ |
9 | __IOM uint32_t FMCCLKE : 1; /*!< [4..4] CRC clock enable */ |
10 | __IOM uint32_t QSPICLKE : 1; /*!< [5..5] QSPICLKE */ |
11 | __IOM uint32_t CRCCLKE : 1; /*!< [6..6] CRCCLKE */ |
12 | __IM uint32_t : 1; |
13 | __IOM uint32_t EMMCCLKEN : 1; /*!< [8..8] FSMC clock enable */ |
14 | __IM uint32_t : 1; |
15 | __IOM uint32_t SDIOCLKE : 1; /*!< [10..10] SDIO clock enable */ |
16 | } AHBCLKEN_B; |
17 | } ; |
Die Kommentare passen leider auch nicht so genau.
In der main.c vom APM32 FPU Beispiel, wird die FPU so initialisiert:
1 | RCM_EnableAHBPeriphClock(RCM_AHB_PERIPH_FPU); |
2 | RCM->CFG |= 0x08000000; |
Das sollte meinem Init entsprechen:
1 | volatile uint32_t *AHBCLKEN = (uint32_t *)0x40021014;/* [3..3] FPU clock enable */ |
2 | volatile uint32_t *FPU_CFGR = (uint32_t *)0x40021004; /* [27..27] FPUDIV */ |
3 | |
4 | *AHBCLKEN = *AHBCLKEN | (1<<3); |
5 | while ( (*AHBCLKEN & (1<<3)) == 0 ){}; |
6 | |
7 | *FPU_CFGR = *FPU_CFGR | (1<<27); |
8 | while ( (*FPU_CFGR & (1<<27)) == 0 ){}; |
Durch das while und auch durch Debug kann ich das setzen der Bits 3 bzw. 27 bestätigen.
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? :-)
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.
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.
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.
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
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.
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.
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?
da sind üblicherweise Device und Registerbeschreibungen die Debugger verwenden. Und der Thread wurde doch schon genug durch irgendwelche Marktwirtschaftsdiskussionen verschandelt.
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
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.
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
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. :(
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.
Angehängte Dateien:
-
APM32F103.png
33 KB
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. :-(
Zitat: "QSPI was added to APM32E series, which supports Standard SPI mode and Quad SPI mode;"
Beitrag #6259262 wurde vom Autor gelöscht.
Angehängte Dateien:
-
APM-E-versus-F.png
20 KB
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 !!!
Geben wir es zu: vom China Mann aufs Kreuz gelegt. Nehmen wir es als normales Bluepill mir echten 128K.
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
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.
ä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?
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.
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?
1 | Arm Cortex -M4 32-bit RISC core operating at a frequency of up to 84 MHz. |
2 | The Cortex®-M4 core features a Floating point unit (FPU) single precision which supports all Arm single-precision data-processing instructions and data types. |
3 | 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
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....
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:
1 | 2747 Takte sin(3.14) = -0.00 |
2 | 2577 Takte sin(3.04) = 0.10 |
3 | 2208 Takte sin(2.94) = 0.20 |
4 | 2208 Takte sin(2.84) = 0.30 |
5 | 2208 Takte sin(2.74) = 0.39 |
6 | 2208 Takte sin(2.64) = 0.48 |
7 | 2208 Takte sin(2.54) = 0.56 |
8 | 2208 Takte sin(2.44) = 0.64 |
9 | 2027 Takte sin(2.34) = 0.72 |
10 | 2027 Takte sin(2.24) = 0.78 |
11 | 2027 Takte sin(2.14) = 0.84 |
12 | 2039 Takte sin(2.04) = 0.89 |
13 | 2027 Takte sin(1.94) = 0.93 |
14 | 1825 Takte sin(1.84) = 0.96 |
15 | 1824 Takte sin(1.74) = 0.99 |
16 | 1824 Takte sin(1.64) = 1.00 |
17 | 1824 Takte sin(1.54) = 1.00 |
18 | 1824 Takte sin(1.44) = 0.99 |
19 | 1824 Takte sin(1.34) = 0.97 |
20 | 2027 Takte sin(1.24) = 0.95 |
21 | 2039 Takte sin(1.14) = 0.91 |
22 | 2024 Takte sin(1.04) = 0.86 |
23 | 2024 Takte sin(0.94) = 0.81 |
24 | 2024 Takte sin(0.84) = 0.75 |
25 | 1051 Takte sin(0.74) = 0.68 |
26 | 1051 Takte sin(0.64) = 0.60 |
27 | 1051 Takte sin(0.54) = 0.52 |
28 | 1051 Takte sin(0.44) = 0.43 |
29 | 1051 Takte sin(0.34) = 0.33 |
30 | 1051 Takte sin(0.24) = 0.24 |
31 | 1051 Takte sin(0.14) = 0.14 |
32 | 1051 Takte sin(0.04) = 0.04 |
:
Bearbeitet durch User
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.
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.
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.
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.
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.
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.
Ich habe einen Geehy AMP32F103 in einem EBike-BLDC Controller. Mit dem STLinkV2 und der STM32 Utility wird er erkannt, allerdings werden aus dem Speicher nur Nullen gelesen, obwohl die originale Firmware noch drauf ist. Gibt es dazu Erfahrungen? Wird hier die ROP nur anders gehandhabt? Ich hatte die Hoffnung, die originale FW sichern zu können, bevor ich meine eigene draufflashe, was ja anscheinend mit dem ST-Werkzeugkasten problemlos geht... Gruß hochsitzcola
Angehängte Dateien:
hochsitzcola schrieb: > allerdings werden aus dem Speicher nur Nullen gelesen Weil der Hersteller das konfiguriert hat. Nennt sich RDP (Read Protection)
Bei manchen µC's kann man den Flash trotz Schutz auslesen: https://www.aisec.fraunhofer.de/en/FirmwareProtection.html Hab ich mal bei einer China Lötstation gemacht. Ich weiß aber nicht, ob das auch beim APM32F103 funktioniert.
Gibt es den EBike-BLDC Controller nicht auch einzeln? Für mein Rad hätte einer 30€ gekostet. War aber nur eine verbrannte Leiterbahn, die ich flicken konnte. Da schwierigste war der Einbau. Dann würde ich den Originalen besser Original lassen.
Stefan F. schrieb: > Weil der Hersteller das konfiguriert hat OK, kenne ich prinzipiell aus den Option Bytes, bei den Originalen bringt das Utility aber eigentlich eine Meldung, daß nicht gelesen werden kann, da die Read Out Protection gesetzt ist.... Aber wurscht. Dann muß ich ohne Sicherung leben.... pegel schrieb: > Dann würde ich den Originalen besser Original lassen. :-) das ist keine Option für meine Anwendung, für die Kommunikation mit dem Drehmomentsensor im Nabenmotor ist eine spezielle Firmware erforderlich... https://www.pedelecforum.de/forum/index.php?threads/analyse-getriebenabenmotor-mit-integriertem-drehmomentsensor-von-kclamber.99213/post-1949248 Gruß hochsitzcola
Moin, Die APM32F103 gibt es auf LCSC.com zu kaufen. Kannst den Originalen Chip ja lassen und einen neuen einlöten... MFG
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.