Vielleicht bin ich einfach nur blind, aber irgendwie fällt es mir schwer
heute Softwarebeispiele von ST zu finden. Zumindest scheint es kaum noch
Source Code zu geben an dem man "mal eben" herankommt nachdem die Ihre
Seite umgestellt haben.
ich will die Software des STM32 digital PFC einsehen, aber statt der
pfc.c die es früher wohl mal gab gibt es nur noch die halb Internet
basierten Software Applikationen.
Es ist schwer das zu erklären, früher gab es alles, heute muss man
gewaltigen Softwareoverhead aufladen um "vielleicht" etwas zu finden.
Gibt es noch ne Seite mit "alten" ST Source Codes, oder darf man jetzt
alles unter NDA anfragen, wo man als kleines Licht nichts mehr bekommt.
Konkret würde mich die Software zum STEVAL-ISF002V1 Board interessieren.
W.S. schrieb:> Das ist ja mal eine unerwartet positive Nachricht.
Eventuell wuchs ST das ja über den Kopf mit den ganzen Laien, die besser
mit Arduino irgendwas zusammenklicken sollten - das sind nämlich die,
welche den ST-Code nicht als Beispiel, sondern als Produktivcode zum
Ersatz fürs Handbuchlesen mißverstanden haben.
guru schrieb:> ich will die Software des STM32 digital PFC einsehen, aber statt der> pfc.c die es früher wohl mal gab gibt es nur noch die halb Internet> basierten Software Applikationen.
...
> Konkret würde mich die Software zum STEVAL-ISF002V1 Board interessieren.
Ich habe mir auch gerade den Wolf gesucht nach den Firmware-Beispielen
für das STM32L053 Discovery Board [1]. Diese hat ST im STM32CubeL0 Paket
versteckt. 70MB ZIP zu Downloaden, obwohl mich nur einige 10KB daraus
interessieren ...
[1] Beitrag "Schnäppchen: STM32L053-Disco mit ePaper-Display für <8€"
guru schrieb:> Zumindest scheint es kaum noch> Source Code zu geben an dem man "mal eben" herankommt nachdem die Ihre> Seite umgestellt haben.
Das ist halt jetzt alles viel benutzerfreundlicher gestaltet...
Axel S. schrieb:> 70MB ZIP zu Downloaden, obwohl mich nur einige 10KB daraus> interessieren ...
Der Registrierungszwang für die Downloads ist ebenso ein Witz. ST mag
gute Hardware herstellen aber mit Software scheinen die es nicht so zu
haben.
Es könnt' alles so einfach sein, is' es aber nicht...
https://www.youtube.com/watch?v=97yxhKL5AUw
Diese Unsitte greift auch bei anderen Herstellern umsich.
Momentan suche ich zum Beispiel ein paar Codeschnipseln um die
USB-Peripherie eines Kinetis in Betrieb zu nehmen, es wird wohl darauf
hinauslaufen das komplette Kinetis-Design Studio zu installieren, eine
halbe Tonne hässlichsten Codes mit dem Assistenten generieren zu lassen
und dann den Rest der Woche damit verbringen die benötigten geschätzten
10kB vorsichtig aus der resultierenden riesigen verwachsenen Müllhalde
herauszuamputieren und in eine benutzbare Form zu überführen.
Offenbar besteht das Zielpublikum nur noch aus dressierten Klickaffen
die nur noch Anwendungen bauen (lassen) für die irgendein Wizard
automatisch generierten Code ausspucken kann, und wenn das nicht passt
nimmt man einfach einen größeren Controller oder zwei davon.
Christopher J. schrieb:> ST mag> gute Hardware herstellen aber mit Software scheinen die es nicht so zu> haben.
Das ist bei allen Hardwareherstellern so. Software ist ein nerviger
Kostenfaktor, die Könige der Firma sind die Hardware-Ingenieure, die
notfalls die Software nebenbei hinrotzen - kann ja nicht so schwer sein.
Blub schrieb:> ST forciert ihr STM32CubeMX ... 4GB installieren für ein wenig> Source> Code ...
Das Problem dabei: Man macht sein Projekt unter Umständen von einer
bestimmten Version dieser Bloatware abhängig.
Und wenn man in 3 Jahren eine winzige Änderung im Projekt machen will,
compiliert der Quatsch nicht mehr, weil man für ein neueres Projekt eine
neue Version von CUBEMX installiert hat. *1)
Dann rollt man entweder die ganze IDE auf einen (nicht mehr
downloadbare) Stand zurück, oder sucht das Problem. Eine winzige
Änderung dauert dann ewig.
Mich nagelt das privat auf PIC24 und PIC32 fest. Dort habe ich meine
selber geschriebenen Treiber für fast alles (Abgetippt aus dem
Datenblatt), ohne PLIB, Harmony und ähnlichen Quatsch. Die kenne ich,
und die compilieren auch 17 Versionen später immer noch und laufen.
D.h. das ist (für mich) wartbar.
Im Gegensatz zu meinem allerersten PIC32 Projekt. Das basiert auf der
peripheral Lib, einem alten Stand. Uncompilierbar...
Wollte mir schon lange mal STM32L ansehen, aber da habe ich die Wahl
zwischen Pest, Aids und Cholera:
- STM32 peripheral lib (sie mag mich nicht, ich sie auch nicht:-))
- CUBE-MX : oben beschriebenes Problem
- Alle Treiber NOCHMAL selber schreiben - geht zwar, bin aber zu faul
*1) so passiert in unserer Firma
Christopher J. schrieb:> Der Registrierungszwang für die Downloads
lässt sich mit ein bisschen URL-Bearbeitung bzw. Vergleich mit
registrierungsfreien Download-Links vermeiden. Siehe auch Direktlinks
hier im Wiki.
Na ja, schlechter Code ist besser als gar keiner, die Datei die ich
suche ist nicht mal eben zu finden, sie war Bestandteil einer für das
Kit programmierten Software. Cube u.s.w. nutzt mir da auch nichts.
Werde mal bei ST fragen, aber fürn "Popo" ist es trotzdem, diese ätzende
Sucherei bei ST.
Bernd K. schrieb:> Momentan suche ich zum Beispiel ein paar Codeschnipseln um die> USB-Peripherie eines Kinetis in Betrieb zu nehmen, es wird wohl darauf> hinauslaufen das komplette Kinetis-Design Studio zu installieren, eine> halbe Tonne hässlichsten Codes mit dem Assistenten generieren zu lassen> und dann den Rest der Woche damit verbringen die benötigten geschätzten> 10kB vorsichtig aus der resultierenden riesigen verwachsenen Müllhalde> herauszuamputieren und in eine benutzbare Form zu überführen.
Du kannst das "Kinetis SDK" installieren, ohne die eigentliche IDE zu
installieren. Darin sind die Treiber, als auch Beispiele enthalten.
Netterweise gibt es bei den Beispielen neben Projektdateien für IAR,
Keil und Co auch noch CMake als Option. Ein USB-CDC Beispiel für ein
Freedom K64F findest du etwa für das KSDK 1.3 in
KSDK_1.3.0/examples/frdmk64f/demo_apps/usb/device/cdc/virtual_com/bm/arm
gcc/
Version 2.0 des KSDK wird nach Bedarf direkt für den Prozessor
generiert. Ist etwas müßig und fummelig bis man sich auf der NXP
Homepage durchgeklickt hat bis man das endlich herunterladen kann aber
alles in allem macht Freescale mMn was Software angeht einen wesentlich
besseren Job als ST.
Bernd K. schrieb:> Offenbar besteht das Zielpublikum nur noch aus dressierten Klickaffen> die nur noch Anwendungen bauen (lassen) für die irgendein Wizard> automatisch generierten Code ausspucken kann, und wenn das nicht passt> nimmt man einfach einen größeren Controller oder zwei davon.
Das stimmt allerdings (leider) trotzdem.
Schall und Rauch schrieb:> lässt sich mit ein bisschen URL-Bearbeitung bzw. Vergleich mit> registrierungsfreien Download-Links vermeiden. Siehe auch Direktlinks> hier im Wiki.
Das wusste ich noch nicht aber es passt zu meinem Eindruck von ST, dass
die ganze Registrierung letztendlich für die Katz ist.
Jack schrieb:> Das ist bei allen Hardwareherstellern so. Software ist ein nerviger> Kostenfaktor, die Könige der Firma sind die Hardware-Ingenieure, die> notfalls die Software nebenbei hinrotzen - kann ja nicht so schwer sein.
Dokumentation scheint auch ein nerviger Faktor zu sein. In der AN4776
("General purpose timer cookbook") von ST sind zwischendrin auch mal ein
paar Zeilen französischer Text zu lesen. Das ist an sich ja kein
Weltuntergang aber es zeigt doch welchen Status das Schreiben von
Dokumentation bei ST hat.
Wenn man erst einmal den Fuß im Markt hat (STm32..)...
Man muss ja auch bedenken das die Dinger doch recht günstig sind.
Oder du kaufst teurer zum Beispiel bei Maxim. Die stellen sogar
"Algorithmen" online. Wobei ob die Qualität dann auch so gut ist wage
ich zu bezweifeln ;-)
Bernd K. schrieb:> Momentan suche ich zum Beispiel ein paar Codeschnipseln um die> USB-Peripherie eines Kinetis...
Bist du dir wirklich sicher, daß du das tun willst? Oder MUSST du das
tun? Als ich beim Lesen der Dokus endlich begriffen habe, daß deren
Taktversorgung zu schlecht ist, um daraus einen brauchbaren 48 MHz für
den USB zu machen, ist mir jegliche Lust am Thema USB mit Kinetis
vergangen. Entweder prügelt man auf den Quarzeingang mit einem externen
48 MHz Quarzoszi ein oder man kriegt Stress mit dem internen 48 MHz
RC-Oszi, der natürlch erstmal per HW+SW (Marke Mampe halb&halb)
kalibriert sein will.
Wenn du kannst, nimm nen anderen µC für sowas.
Christopher J. schrieb:> aber> alles in allem macht Freescale mMn was Software angeht einen wesentlich> besseren Job als ST.
Ich schätze, HW * SW ist ne Art Konstante.
W.S.
W.S. schrieb:> daß deren> Taktversorgung zu schlecht ist, um daraus einen brauchbaren 48 MHz für> den USB zu machen, ist mir jegliche Lust am Thema USB mit Kinetis> vergangen. Entweder prügelt man auf den Quarzeingang mit einem externen> 48 MHz Quarzoszi ein
Nein, warum? Wovon sprichst Du? 4MHz oder 8MHz Quarz dran, PLL auf 96MHz
stellen und gut ist.
Was ich im Moment viel hinderlicher finde ist die Tatsache daß es für
die KLxxZ32 Varianten (32k Flash) scheinbar unmöglich ist mit den
offiziellen Tools (KDS, SDK, Processor-Expert) ein leeres Projekt (nur
USB, sonst nichts) zu erzeugen das mit weniger als 32k Flash auskommt.
Also wer gesagt hat daß Kinetis an der Softwarefront weniger Schrott
bauen würde als ST, das kann mich nicht so recht überzeugen. Ich hab mal
ganz naiv das getan was die anderen User auch machen (sollen): KDS
installiert, SDK installiert, neues Projekt erzeugt (ohne alles): 10kB
Flash. -Os: immer noch 8kB.
Das ist mehr als ich bei ST je gesehen habe, da waren es glaub ich nur
4k und auch das erst als ich angefangen habe GPIO zu benutzen.
Jetzt noch die Usb-HID-Maus-Komponente reingezogen: Game over: region
`m_text' overflowed by 3092 bytes
Ich bin grad ein bisschen sprachlos, aber ich will jetzt auch nicht den
Thread kapern der ja um ST-Software geht. Ich hab nur den Eindruck daß
es bei Freescale/NXP kein bisschen rosiger aussieht und man wenn man die
kleineren Prozessoren verwenden will den zusammengeklickten
HAL-SDK-Monster-Bloat nicht mehr sinnvoll einsetzen kann und eh alles Zu
Fuß implementieren muß (dann kommt man locker unter 4k) aber wenn man
diesen Weg gehen muß bekommt man Null Hilfestellung.
Bernd K. schrieb:> 10kB> Flash. -Os: immer noch 8kB.
Omg, meine ganze Firmware für einen 3D-Drucker hat auf meinem Nucleo
F411RE gerade einmal 12kB. Mit SPI, ADC über DMA, ein paar Timer und was
man sonst so noch gerade braucht.
Natürlich ohne irgend eine Lib von STM.
Bernd K. schrieb:> KDS installiert, SDK installiert, neues Projekt erzeugt (ohne alles):> 10kB Flash.
Welchen Compiler nutzt Du? GCC? Dann kann's an printf liegen, das
irgendwer irgendwo unnützerweise da reingepfriemelt hat. Entweder mal
mit nanolib linken oder ganz ohne Libs und gucken, ob der Linker mault.
Nop schrieb:> Welchen Compiler nutzt Du? GCC? Dann kann's an printf liegen, das> irgendwer irgendwo unnützerweise da reingepfriemelt hat. Entweder mal> mit nanolib linken oder ganz ohne Libs und gucken, ob der Linker mault.
Das nutzt das was mir deren Installationsprogramm auf die Festplatte
geklatscht hat, also laut deren Aussagen ein gemoddeter gcc (nicht das
Orginal von Launchpad, aber egal) und der "irgendwer" der da ein printf
reingefriemelt hat scheint bei Freescale zu arbeiten und irgendwie nicht
ganz den Zweck seiner Aufgabenstellung erfasst zu haben, denn das hätte
ein leeres Projekt (nicht mal Blinky oder dergleichen) sein sollen,
dennoch strotzt der erzeugte Code nur so von printf-Geraffel und zwei
Dutzend verschiedenen Integer-Divisions und Multiplikationsroutinen in
allen Varianten, signed und unsigned, lang und kurz und wahrscheinlich
ist auch noch ne halbe Tonne float mit drin, ich musste relativ schnell
meinen Blick abwenden weil mir übel wurde.
Ich hab keine Lust nachträglich an deren generiertem Code herumzudoktorn
(der übrigens so hässlich aussieht daß es die Sau graust und auch
gefühlt jede dritte Zeile von einem #ifdef ausgegraut ist).
Entweder das würde funktioniern und ich könnte mich damit abfinden das
als Black-Box zu nutzen und einfach niemals einen Blick in diesen
generierten Saustall reinzuwerfen oder der generierte Code ist komplett
für die Tonne weil demjenigen der den Codegenerator und die Fragmente
die dieser ins Projekt erbricht entworfen hat niemand gesagt hat daß es
hier um embedded (klein und leichtgewichtig, passend zu den kleinen
Freescale Kinetis MCUs) geht und nicht um tonnenschwere Anwendungen für
Windows Desktops. Ich tendiere stark zur Tonne.
Würde der generierte Code kein printf (mit allen Integer und Float
Datentypen - daher die ganzen Konvertierungsfunktionen) und malloc
unterstützen, würde der nächste jammern. Egal wie man es macht, ist es
falsch... Anstatt wortreich zu lästern sollte man die entsprechenden
Dateien und Linker Flags rauswerfen und sich freuen.
> für die Tonne weil demjenigen der den Codegenerator und die Fragmente> die dieser ins Projekt erbricht entworfen hat niemand gesagt hat daß es
Reg dich nicht auf. Diejenigen die so einen Kram schreiben das sind
Studenten die fuer ein paar Taler nebenbei fuer ST arbeiten.
Und diejenigen die sowas nutzen sind Bacherlors frisch von der Uni.
Olaf
Dr. Sommer schrieb:> Anstatt wortreich zu lästern sollte man die entsprechenden Dateien und> Linker Flags rauswerfen und sich freuen.
Und dann tagelang den kaputten generierten Code flicken damit er wieder
funktioniert? Und danach die tolle neue IDE nicht mehr verwenden können?
Also die Nachteile aus beiden Welten vereinen? Nein danke.
Bernd K. schrieb:> dennoch strotzt der erzeugte Code nur so von printf-Geraffel und zwei> Dutzend verschiedenen Integer-Divisions und Multiplikationsroutinen in> allen Varianten, signed und unsigned, lang und kurz und wahrscheinlich> ist auch noch ne halbe Tonne float mit drin
OMG.. ja, da hat man in der Tat keine Fragen mehr offen. Eventuell ist
das ja auch als Verkaufshilfe für die größeren, teureren Controller zu
sehen. Andererseits soll man ja nie mit planvollem Handeln erklären, was
sich auch durch Unfähigkeit erklären läßt.
Bernd K. schrieb:> Nein, warum? Wovon sprichst Du? 4MHz oder 8MHz Quarz dran, PLL auf 96MHz> stellen und gut ist.
Wovon schreibst du?
Also, die Typen, die ich unter den Fingern gehabt habe, besitzen keine
PLL, sondern nur eine sogenannte FLL.
Und deren input ist 32..39 kHz und keine 4 oder 8 MHz. Man kann zwar
4..8 MHz verwenden, aber nur dann, wenn man deren Takt auf den Bereich
32..39 kHz herunterteilt. Und dafür gibt es nicht mal nen frei
einstellbaren Teiler, sondern nur was fest eingestelltes. Tja, und deas
Signal eben diser FLL ist das Grausige. Lies mal die Appnotes von
Freescale zu diesem Thema. Da schüttelt es einen.
Mal ein paar Auszüge aus dem Refman zum MK22F128:
"IRC48 with clock-recovery is supported to eliminate the 48 MHz crystal.
It is used for USB device-only implementation."
"41.4.29 USB Clock recovery control (USBx_CLK_RECOVER_CTRL)
Signals in this register control the crystal-less USB clock mode in
which the internal IRC48M oscillator is tuned to match the clock
extracted from the incoming USB data stream."
Reicht's?
W.S.
W.S. schrieb:> Wovon schreibst du?> Also, die Typen, die ich unter den Fingern gehabt habe, besitzen keine> PLL, sondern nur eine sogenannte FLL.
Der KL26Z32 (der kleinste aus der L-Reihe mit USB und der den ich
verwenden will) hat auch eine PLL die man stattdessen verwenden kann.
Die größeren wahrscheinlich erst recht.
