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.
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.
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 ...
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.
;-)
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.
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. ;-)
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!
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 ...
/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.
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?
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. :(
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, 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 ...
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 ...
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. ;-)
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.
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 ...
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.
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.
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?
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).
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
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.
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:
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.
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.
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
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
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 ...
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.
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
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.
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:
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!
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. ;-)
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?
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 ...
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.
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.
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.
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!
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.
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:
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
hochsitzcola schrieb:> allerdings werden aus dem Speicher nur Nullen gelesen
Weil der Hersteller das konfiguriert hat. Nennt sich RDP (Read
Protection)
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.
Thread beobachten
Seitenaufteilung abschalten