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.
guru schrieb: > Zumindest scheint es kaum noch > Source Code zu geben Das ist ja mal eine unerwartet positive Nachricht. W.S.
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.
:
Bearbeitet durch User
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.
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.