Hallo Der STM32F730R8T6 bietet ein tolles P/L verhältnis. Weshalb ich diesen gerne kurzerhand einsetzen werde. Bin STM32 neuling. Daher kurz Fragen um nicht in der doku rumstöbern zu müssen: 1. Existiert ein Basisschemabild mit all den Spannungen, resets, clk, JTAG o.ä. die der STM32F730R8T6 benötig damit er läuft. (soll mit minimal möglicher bom loslaufen); oder bitte kurz beschreiben welche signale benötigt werden 2. Wie JTAGEN und welche fuses setzen, damit er auf 216mhz mit internem osc losläuft? 3. Oder geht dies beim STM32 direkt über den USB (programieren und debug fuses setzen)? 4 Wie am einfachsten programieren und debuggen? 5. Existiert ein gutes HAL? Link zur lib? 6. welche IDE damit direkt mit jtag in system debugt werden kann?
Ich empfehle dir dringend, mit einem kleineren STM32 anzufangen. Suche Dir einen aus: http://stefanfrings.de/stm32/index.html Deine Fragen sind dort beantwortet, falls ich mal so frei sein darf, JTAG durch SWD zu ersetzen und Fuses durch Option Bytes.
STM32 schrieb im Beitrag #6006511: > 1. Existiert ein Basisschemabild mit all den Spannungen, resets, clk, > JTAG o.ä. die der STM32F730R8T6 benötig damit er läuft. (soll mit > minimal möglicher bom loslaufen); oder bitte kurz beschreiben welche > signale benötigt werden Ja, siehe z.B. jedes Nucleo-Board > 2. Wie JTAGEN und welche fuses setzen, damit er auf 216mhz mit internem > osc losläuft? CubeMX > 3. Oder geht dies beim STM32 direkt über den USB (programieren und debug > fuses setzen)? Ja > 4 Wie am einfachsten programieren und debuggen? Ich verstehe die Frage nicht ;) > 5. Existiert ein gutes HAL? Link zur lib? Ja, siehe z.B. CubeMX > 6. welche IDE damit direkt mit jtag in system debugt werden kann? Atollic True Studio Zum Einstieg würde ich dir einfach ein Nucleo-Board empfehlen, damit kannst du dann etwas rumprobieren. Zahlreiche Beispiele gibt es dafür auch
Bevor du ein SpaceShuttle baust solltest du vielleicht erstmal mit einem Segelflugzeug anfangen! Besorg dir ein Nucleo-Board mit einem STM32F1xx oder STM32F3xx. Damit hast du als Anfänger bereits genug Herausforderungen. Software (CubeMX, CubeIDE etc.) gibts bei ST. CubeIDE ist der offizielle Nachfolger von Attolic TrueStudio. STM32 schrieb im Beitrag #6006511: > um nicht in der doku rumstöbern zu müssen Mit so einer Einstellung wird das aber sowieso nix.
:
Bearbeitet durch User
Christian W. schrieb: > Atollic True Studio Kleiner Hinweis: Das Atollic Studio wird nicht mehr weiter gepflegt. Sein Nachfolger heißt "STM32 Cube IDE". An den TO: Lass dich durch die vielen "Cubes" in den Produkten von ST nicht verwirren. Cube ist nicht der Weisheit letzter Schluss - es gibt auch ein Leben ohne Cubes.
Aber er will ja keine Dokus lesen, also ist er auf Gedeih und Verderb den Würfeln ausgeliefert ;) Die 64k Flash dürften aber ziemlich schnell voll sein.
Mw E. schrieb: > Aber er will ja keine Dokus lesen Man kann das auch anders interpretieren: Er sucht ein paar Einstiegshilfen für erste Erfolgserlebnisse. Erst danach möchte er sich in die Details einlesen.
Christian W. schrieb: >> 2. Wie JTAGEN und welche fuses setzen, damit er auf 216mhz mit internem >> osc losläuft? > CubeMX Der CubeMX ist der Oberhammer. Danke für den Tipp, da wird mit geholfen. Sogar die DMAs mit ein paar kliks konfiguriert. Stefanus F. schrieb: > An den TO: Lass dich durch die vielen "Cubes" in den Produkten von ST > nicht verwirren. Cube ist nicht der Weisheit letzter Schluss - es gibt > auch ein Leben ohne Cubes. Nun mit ein paar minuten ein bisschen rumklicken hat man alle DMAs konfiguriert, den STM auf 216MHz, ADC, USART etc. Da wird wohl kein experte manuell mit dem Cube mithalten können. BTW: 2 Sachen sind mir aufgefallen. Der USART kann Asynchron 27mbaud jedoch synchron "nur" die hälfte. Oversampling kann ich nicht unter 8 senken. Ist asynchron mit 27mbaud noch stabil? (wohl kaum mit dem interen clk). Jedoch bei Synchron sehe ich kein problem, auch mit 50Mbaud+ das kann der STM aber nicht. Gibts da irgend ein workaround. Solche hohe Datenraten würden bei der Kommunikation mit dem FPGA erleichtern (nur noch 2 Leitungen).
STM32 schrieb im Beitrag #6006701: > Nun mit ein paar minuten ein bisschen rumklicken hat man alle DMAs > konfiguriert, den STM auf 216MHz, ADC, USART etc. Da wird wohl kein > experte manuell mit dem Cube mithalten können. Wenn es dann auch so läuft, so sei es. ? Aber mach dich dann, solltest du dies dann Plains auf deinen STM flashen und debugen, auf eine kleine Überraschung gefasst. Denn: initialisiert sind sie zwar, aber nicht gestartet, selbst der clock nicht. So war es zumindest als ich mal mit Cube experimentiert habe. Und wenn man die Register dann irgendwann mal im Kopf hat (ich geb zu, dies dauert ein wenig) dann ist man per Hand allemal schneller als mit Cube. Und man ist dann auch NICHT auf die Cube-HAL angewiesen. Ganz im Gegenteil, man bastelt dann mit der Zeit seine eigene Lob zusammen, mit dem was man wirklich auch braucht ohne irgendwelchen Balast mit zu schleifen. Übrigens kann ich Stefan Frings Seite (siehe weiter oben) nur ans Herz legen, damit habe ich auch angefangen und die ersten Schritte damals gemacht.
STM32 schrieb im Beitrag #6006701: > Ist asynchron mit 27mbaud noch stabil? 27 Millibaud sind kein Problem. Man muß den Kern nur entsprechend langsam laufen lassen. Mw E. schrieb: > Die 64k Flash dürften aber ziemlich schnell voll sein. Aber nur für Schwätzer. Wenn man bedenkt, daß ein ATmega328 nur 32 KB hat, dann ist da noch reichlich Luft nach oben ;-) STM32 schrieb im Beitrag #6006511: > Der STM32F730R8T6 bietet ein tolles P/L verhältnis. So sieht es aus!
m.n. schrieb: > Mw E. schrieb: >> Die 64k Flash dürften aber ziemlich schnell voll sein. > > Aber nur für Schwätzer. Wenn man bedenkt, daß ein ATmega328 nur 32 KB > hat, dann ist da noch reichlich Luft nach oben ;-) Sprach der Oberschwätzer. So ein F7 ist eine etwas größere MCU in dem man dann auch etwas größere Projekte packt. Mein Wirkleistungsmessgerät braucht jetzt schon 100k mit ein paar Grafiken und 3 fonts. Da kommt dann noch ein USB Stack rein für Screenshots und loggen auf USB Stick. Also der Herr: nicht dumm rumlabern, dass 64k ausreichen, sondern mal was machen. Ich seh grade im mapfile, dass die Koeffizienten von der CMSIS FFT Lib auch nett was an .rodata brauchen. Obwohl ich alle FFTs über 512 bins schon gekillt habe. Ist eben ein größeres Projekt was auch die harmonischen Verzerrungen von Netzspannung und Strom erfasst :) Beitrag "Re: Zeigt her eure Kunstwerke (2019)" Also liefer erstmal due Oberschwätzer. Bisher biste hier durch dummes rumtrollen im Forum aufgefallen!
Die H7 mit ein bisschen Flash sind dafür ausgelegt um extern per QSPI einen Seriellen Falsch anzubinden. Im internen Flash liegt nur ein Bootloader mit etwas Kleinkram... Man kann damit sogar einen Bootloader schreiben um die eigentliche FW von SD Karte zu starten. ( Siehe DISCO H750 board ) Der Adressbereich wird durch das QSPI in den interen gemappt!! Stichwort Xip ( Execute in Place ) https://www.st.com/content/ccc/resource/technical/document/application_note/group0/d8/39/10/2f/ee/c9/4b/19/DM00514974/files/DM00514974.pdf/jcr:content/translations/en.DM00514974.pdf Somit kann man wunderbar einen H7xx mit 8MB Flash verbauen um Preis eines F7xx mit 512KB internem FLash. Das ganze ist eher in Konkurenz zum NXP RT105x/106x gedacht.
Mw E. schrieb: > Mein Wirkleistungsmessgerät braucht jetzt schon 100k mit ein paar > Grafiken und 3 fonts. > ... > Ist eben ein größeres Projekt was auch die harmonischen Verzerrungen von > Netzspannung und Strom erfasst Wer braucht denn schon ein Wirkleistungsmessgerät? Mach doch mal was Sinnvolles. Der F730 ist eben nichts für Dich. Für größere Projekte gibt es auch Derivate mit größerem Flash. Wer viele bunte Bilder nicht lassen kann und dann noch alle Schnittstellen braucht, weil er sich nicht auf eine sinnvolle Auswahl beschränken kann, wird auch mit 2 MB Flash nicht hinkommen. Oder anders formuliert: die kleinen Prozessoren funktioniern auch noch, wenn man nur 10% der vorhandenen Hardware nutzt. Die F730er sind nicht deshalb so günstig, weil STM Ladenhüter produziert hat, die sie jetzt loswerden möchten, sondern weil sie einen Markt für kleine, leistungsfähige µCs haben.
m.n. schrieb: > STM32 schrieb im Beitrag #6006701: >> Ist asynchron mit 27mbaud noch stabil? > > 27 Millibaud sind kein Problem. Man muß den Kern nur entsprechend > langsam laufen lassen. sorry, meinte natürlich 27 Mbaud
m.n. schrieb: >> Die 64k Flash dürften aber ziemlich schnell voll sein. > Wenn man bedenkt, daß ein ATmega328 nur 32 KB > hat, dann ist da noch reichlich Luft nach oben Andererseits belegt gleicher Code auf ARM Controllern oft deutlich mehr FLASH, als der gleiche Code auf ARM Controllern. Wenn man Cube HAL verwendet sogar sehr viel mehr.
m.n. schrieb: > Wer braucht denn schon ein Wirkleistungsmessgerät? Ist doch egal, solange es bezahlt wird.
m.n. schrieb: > Die F730er sind nicht deshalb so günstig, weil STM Ladenhüter produziert > hat, die sie jetzt loswerden möchten, sondern weil sie einen Markt für > kleine, leistungsfähige µCs haben. Das und weil sonst NXP mit der RTSerie gerade hier nur halb so viel kostet. Die fetten Brummer mit Leistung können daher auch mit externem Flash betrieben werden. Denn für Anwendungen mit Grafiken und Co ... reichen oft auch die 512/1MB/2MB Typen nicht aus. Der externe Flash ist durch vergrößern des Cach nicht so viel langsamer. Kritischer Code passt immernoch in den ITCM und ist auch hier dank 480Mhz sau schnell.
hfhd schrieb: > Denn für Anwendungen mit Grafiken und Co ... > reichen oft auch die 512/1MB/2MB Typen nicht aus. Das hat aber ein Sinclair ZX-Spectrum in Farbe bereits mit 16k ROM und 48k RAM bei 3,5 MHz hinbekommen! Man muss einfach programmieren können.
hfhd schrieb: > Das und weil sonst NXP mit der RTSerie gerade hier nur halb so viel > kostet. Nenn mal ein paar Daten. Welcher Typ, welcher Preis? Dann kann man Preis/Leistung bewerten.
Route_66 H. schrieb: > Das hat aber ein Sinclair ZX-Spectrum in Farbe bereits mit 16k ROM und > 48k RAM bei 3,5 MHz hinbekommen! > Man muss einfach programmieren können. richtig. heutzutage klatscht der designer mit photosop was zusammen. die GUX designerin malt animationen rein und dann darf man sich ne platte machen wie man das hinbekommt. in 3 Tagen fertig hört man dann nur ... und multiformat .. multilanguage ... transparent und overlay
m.n. schrieb: > Nenn mal ein paar Daten. Welcher Typ, welcher Preis? > Dann kann man Preis/Leistung bewerten. NXP RT105x oder RT106x -> STM32H750 liegt bei 3€ ... je nach stückzahl
der kleine F730 liegt irgendwo < 1,50€ NXP RT1010 - 1020
https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/i.mx-rt-series:IMX-RT-SERIES sorry .. vlt kann ein MOD das fix zusammenkopieren
Habe gerade den STM32H743ZIT6U von der H serie gefunden. Dieser hat nen 16Bit ADCs welche ansonsten je ca 5 usd kosten separat. Und haten ebenfalls nochmals etwas mehr dampf. Und 2MB Flash und 1 MB RAM :-). Kann die H serie ohne externes Flash laufen? Bei Mouser ist der für ca 10Eur zu haben :-)
Es können alle ohne externen Flasch laufen. Denn alle haben intern ja einen vorhanden Die F7 und H7 Value serie hat aber nur einen kleinen internen. Aber alle neueren können auch von QSPI das Programm ausführen.
hfhd schrieb: > Die F7 und H7 Value serie hat aber nur einen kleinen internen. Worin liegt genau der Unterschid zwischen F7 und H7? Lediglich preis und höhere CPU performance?
hfhd schrieb: > der kleine F730 liegt irgendwo < 1,50€ > > NXP RT1010 - 1020 Den Preis < 1,50 für F730 kann ich nicht finden. Ein flüchtiger Blick ins Datenblatt: RT1010/20 haben kein internes Flash und nur rel. wenig RAM, was zudem noch das Anwendungsprogramm aufnehmen muß. Die Timer laufen mit max 60 MHz. Mich haut das jetzt nicht vom Hocker.
Angehängte Dateien:
-
USART480.PNG
230 KB
Ich habe kurz den Hz in den Cube geladen. Anscheinend kann der USART mit 480MHz betrieben werden, dies widerspricht jedoch den Datenblatt?!? Ist der Cube oder das Datenblatt verbugt? Weshalb kann ich nicht den exteren quarz wählen?
Stefanus F. schrieb: > m.n. schrieb: >> Wer braucht denn schon ein Wirkleistungsmessgerät? >> Mach doch mal was Sinnvolles. > > Ist doch egal, solange es bezahlt wird. An diesen Worten erkennt man den labernden Troll ;) Damit ist nicht Stefanus gemeint. hfhd schrieb: > Die H7 mit ein bisschen Flash sind dafür ausgelegt um extern per QSPI > einen Seriellen Falsch anzubinden. > > Im internen Flash liegt nur ein Bootloader mit etwas Kleinkram... Im prinzip ja, aber wir reden hier über F/ und nicht H7. Du meinst den H750? Der hat ja noch mehr Bang per Buck wegen 400MHz und der H7 Peripherie. Den gibts ja inzwischen für 5€. Direkt mit dem QSPI arbeiten ist für einen ANfänger dann auch etwas viel zum Anfang. Aber das kann man dann so machen. STM32 schrieb im Beitrag #6007239: > Habe gerade den STM32H743ZIT6U von der H serie gefunden. Dieser hat nen > 16Bit ADCs welche ansonsten je ca 5 usd kosten separat. Ja schon, aber die 16Bit da rauszuholen ist nicht einfach. Die CPU streut da tlw rein, für 16Bit musste auch schon beim layout aufpassen. In einem Nachbarthread hier im Forum ist ja schon einer beim 12Bit ADC über Probleme gestolpert. STM32 schrieb im Beitrag #6007247: > Worin liegt genau der Unterschid zwischen F7 und H7? > Lediglich preis und höhere CPU performance? Mach doch mal das Datenblatt fom F730 auf und vom H750. Dann guck dir die Blockdiagramme an. zB sind die DMA Controlelr ganz andere. Endlich keine feste Zuweisung von DMA+Stream+Channel zu einer Peripherie mehr, sondern DMA Request Multiplexer. Super Sache! Ansonsten ist der Businterconnect komplett anders und viel mehr Peripherie. Ansonsten gibts auch schon H7 mit Dualcore: ein M7 und ein M4.
Mw E. schrieb: > Direkt mit dem QSPI arbeiten ist für einen ANfänger dann auch etwas viel > zum Anfang. Muss irgend etwas spezielles beim Cube beachtet werden, wenn man kein externes Flash (kein QSPI) etc haben möchte und lediglich das interne Flash beim H743VIT benutzen möchte. Einfach nach cube init zeugs direkt in mein main(). Das P/L sieht beim H743 überragender aus als beim F7, und dank dem Cube solls ahoffentlich auch einfach gehen...
Mw E. schrieb: > Mein Wirkleistungsmessgerät braucht jetzt schon 100k mit ein paar > Grafiken und 3 fonts. ... meiner liegt bei 32k mit fft, du scheinst ja talent zum rumlabern zu haben! mit 100k fliegt eine rakete locker zum mond. mt
STM32 schrieb im Beitrag #6007883: > dank dem Cube solls ahoffentlich auch einfach gehen... Ich glaube du gehst das ein bisschen zu naiv an. Ich weiß, dass diverse Firmen und Consulter seit mindestens 30 Jahren propagieren, man könne sich ganze Programme zusammen klicken und brauche daher keine richtigen Programmierer mehr. Glaube mir: Es funktioniert so nicht - auch nicht mit Cube Mx. Programmieren muss man trotzdem noch. Es verschiebt sich nur allmählich immer mehr von der Tastatur zur Mausbedienung. Was bleibt ist jedoch, dass man talentierte Programmierer braucht, die große Aufgabe in kleine zerlegen, Anforderungen klären, mit den technischen Möglichkeiten in Einklang bringen und zig-tausende Seiten Datenblätter/Anleitungen verstehen. In deinem Fall siehst du schon jetzt, dass Cube Mx kein Allheilmittel ist. Du hast eine Einstellung gefunden, die Dir zweifelhaft vorkommt. Nun brauchst du Hilfe von andere Experten, die sich nicht alleine auf Cube Mx verlässt und durch seine Erfahrung einschätzen kann, ob Cube Mx das richtige tut. Fällt Dir was auf? Du hast Hirn-Aktivität durch einen Automaten ersetzt, der wiederum seinen eigenen Betreuer braucht. Am Ende musst du dich doch mit Datenblättern und Referenzhandbüchern auseinander setzen - zusätzlich zu der miesen Doku der Cube Hal. Ich sehe da nur begrenzten Mehrwert, wenn man zahlreiche STM32 Modelle einsetzt und sich nicht mit den kleinen gemeinen Unterschieden auseinander setzen will.
Stefanus F. schrieb: > Andererseits belegt gleicher Code auf ARM Controllern oft deutlich mehr > FLASH, als der gleiche Code auf ARM Controllern. Wenn man Cube HAL > verwendet sogar sehr viel mehr. Ist das hier das Politikforum???
Apollo M. schrieb: > meiner liegt bei 32k mit fft Welche FFT ist das? Die CMSIS DSP FFT hat wirklich 2 sehr große Arrays mit Coeffs. Dafür ist die aber auch verdammt schnell. const q15_t __ALIGNED(4) realCoefAQ15[8192]; const q15_t __ALIGNED(4) realCoefBQ15[8192]; Das sind alleine schon 32k. Der USB Host STack mit MSC für den USB STack ist auch nicht grade klein. Da müsst ich jetzt aber Erbsenzählen gehen im mapfile. Apollo M. schrieb: > mit 100k fliegt eine rakete locker zum mond. Die AGC Restauration hab ich mir angesehen. Der war aber ohne GUI ;) Apollo M. schrieb: > du scheinst ja talent zum rumlabern zu haben! Kann sein, aber von dir ließt man hier echt wenig intelligentes im Forum. Irgendwie sind das immer dieselben hier im Forum die blöd rumtrollen.
STM32 schrieb im Beitrag #6006511: > 2. Wie JTAGEN und welche fuses setzen, damit er auf 216mhz mit internem > osc losläuft? Vorsicht an dieser Stelle - ich weiß es beim F7 nicht, aber der F4 kann laut Refman USB nicht mit internem OSC, weil der nicht präzise genug ist. Dazu ist ein externer XTAL zu verwenden.
STM32 schrieb im Beitrag #6007883: > Muss irgend etwas spezielles beim Cube beachtet werden, wenn man kein > externes Flash (kein QSPI) etc haben möchte und lediglich das interne > Flash beim H743VIT benutzen möchte. Also ich arbeite eher wenig mit dem Cube, weil der erzeugte Code sehr buggy ist. Villeicht ist das inzwischen etwas besser als früher, aber es war zum Haare raufen. Bis der oben gesagte USB Host Stack mit MassenspeicherKlasse lief musste ich 3 CubeMX Versionen ausprobieren. Im Cube klick ich mir egentlich nur die GPIOs, weil die ja an mehreren Pins das Licht der Welt erblicken können. Aber ich kann dir sagen: Der Cube geht von alleine davon aus, dass der Code im internen Flash landet. Also musste nichts weiter einstellen. Erst wenn du einen QSPI Flash ranhängen wiillst wirds komplizierter. Aber wie das dann mit dem Cube gehen soll kann ich dir nicht sagen. STM32 schrieb im Beitrag #6007883: > Einfach nach cube init zeugs direkt > in mein main(). Code packst du dahin wos dir erlaubt ist. USercode start bis usercode end. Sonst ist das wech nach dem nächsten Codegen. Mal eben die UART Baudrate ändern? -> neuen Code erzeugen, weil sonst das Structinit wech is mit der neuen baudrate.
STM32 schrieb im Beitrag #6006511: > Der STM32F730R8T6 bietet ein tolles P/L verhältnis. Weshalb ich diesen > gerne kurzerhand einsetzen werde. Bin STM32 neuling. STM32 schrieb im Beitrag #6007239: > Habe gerade den STM32H743ZIT6U von der H serie gefunden. Was hast Du eigentlich vor? Willst Du als STM32-Neuling gleich mit den dicksten Teilen anfangen? Für einen Anfänger ist der F730 schon eine gute Herausforderung. Der R8T6 hat ein LQFP64-Gehäuse, wodurch er für eigene kleine Schaltungen sehr brauchbar ist. Mein Tipp wäre, einen Typ mit pinkompatiblem >= LQFP100-Gehäuse zu wählen, weil Du dann Deine Schaltung mit diversen F7xx bzw. H7xx Derivaten verwenden kannst. Laß Dich nicht von der Klickerei in CubeMX irritieren, sondern lies das Referenzhandbuch von vorne bis hinten durch. Dann kannst Du erahnen, was Dich erwartet. Stefanus F. schrieb: > Andererseits belegt gleicher Code auf ARM Controllern oft deutlich mehr > FLASH, als der gleiche Code auf AVR (hab's korrigiert) Controllern. Da möchte ich widersprechen. 1:1 Portierungen von AVR auf Cortex-M7 Controller nutzen den µC nicht richtig aus. Programme von M7 auf AVR zu portieren scheitert zum einen an der nicht entsprechenden Peripherie und zum anderen an der erheblich reduzierten Ausführungsgeschwindigkeit. Mw E. schrieb: > Irgendwie sind das immer dieselben hier im Forum die blöd rumtrollen. Freitag ist vorbei, komm mal wieder runter. Du bist hier nicht das Maß aller Dinge.
m.n. schrieb: > Mw E. schrieb: >> Irgendwie sind das immer dieselben hier im Forum die blöd rumtrollen. > > Freitag ist vorbei, komm mal wieder runter. Du bist echt lustig. Erst andere als Schwätzer betiteln und wenns dann etwas hitzig wird sich darüber wundern. Da gibts son Sprichwort: Wies in den Wald hineinschallt so schallts auch wieder hinaus. Also fass dir erstmal an die eigene Nase und lern für die Zukunft mal etwas gutes Benehmen.
Mw E. schrieb: > Du bist echt lustig. So sieht es aus. Darum verwende ich auch gelegentlich ein: ;-) Wer das nicht versteht, zieht sich den unpassenden Schuh an und fühlt sich noch draufgetreten. Deine Reaktionen sind schon aufschlußreich. Nimm Dich einfach nicht so wichtig.
Korrektur für einen Tippfehler: > Andererseits belegt gleicher Code auf ARM Controllern oft deutlich mehr > FLASH, als der gleiche Code auf ARM Controllern. Wenn man Cube HAL > verwendet sogar sehr viel mehr. Sollte heissen: Andererseits belegt gleicher Code auf ARM Controllern oft deutlich mehr FLASH, als der gleiche Code auf AVR Controllern. Wenn man Cube HAL verwendet sogar sehr viel mehr. Es ging mir den Flash Bedarf von um ARM versus AVR. Gnorm schrieb: > Ist das hier das Politikforum??? Ich verstehe deine Frage nicht. Beantwortet meine Korrektur sie?
ja das ist leider so aber das ist nunmal der preis der 8bit vs. 32bit architektur HAL brauch ab optimierung O2 nixcht mehr viel ^^ OK die globalen structuren benötigen RAM aber ich z.B arbeite mit HAL + RTOS in der HAL selbst sind die states quasi "halbwegs" sicher so das mehrere tasks nict zeitgleich zugreifen könnten ohne das müsste man das selbst reinprogrammieren HAL an sich funktioniert so gesehen auch STM32 übergreifend recht gut. aber es steht auch nirgends das man HAL nutzen MUSS man kann es .. nimmt man es .. ist man vieleicht zu faul :D
Gnorm schrieb: > Ja. Das waren Saetze ohne irgendeine Aussagekraft... dito bei meinem text hilft es vielleicht die entscheidung HAL + RTOS zu nutzen oder eben nicht ... ich möchte auf M4 oder M7 nicht mehr ohne RTOS arbeiten wenn man das mal raus hat wie das funktioniert ist das genial
Also ich meinte Stefanus, du warst nur zur falschen Zeit am falschen Ort...
bulimie-code schrieb: > ich möchte auf M4 oder M7 nicht mehr ohne RTOS arbeiten > wenn man das mal raus hat wie das funktioniert ist das genial Hat das RTOS entsprechende treiber für ADC USART etc... welche einfacher sind als das HAL und stabiler sind als der Cube vor welchem ich mehrfach gewarnt wurde? Rtos hat ein Treiber für jede CPU, oder benutzt RTOS den cube HAL?
STM32 schrieb im Beitrag #6009655: > bulimie-code schrieb: > ich möchte auf M4 oder M7 nicht mehr ohne RTOS arbeiten > wenn man das mal raus hat wie das funktioniert ist das genial > > Hat das RTOS entsprechende treiber für ADC USART etc... welche einfacher > sind als das HAL und stabiler sind als der Cube vor welchem ich mehrfach > gewarnt wurde? > > Rtos hat ein Treiber für jede CPU, oder benutzt RTOS den cube HAL? Ich nutze freertos Mit hal Und wenn es den Treiber nicht gibt , wird er eben geschrieben... ..
Bulimie-code schrieb: > Und wenn es den Treiber nicht gibt , wird er eben geschrieben... .. Und dann hoffentlich auch veröffentlichtt? Naja der einzige Grund für mich auf ein OS zurückzugreifen ist, dass man eben keinen Treiber schreiben muss. Wie ich gehört habe ist das Cube hal nicht so gelungen. Weiter wird die Doku bemängelt. Evtl. könnte sich ST überlegen besser da nachzubessern anstellen immer breiterer sinnloser Produktpalete.
mich interessiert am OS eher das Task- und memory management Treiber gehen immer .. egal ob registerzugriffe direkt, HAL , LL oder was weiß ich Treiber wären NIE ein grund für mich ein OS zu nutzen. Wenn man mal mit den Taks richtig gearbeitet hat ist es ein Traum.
Wenn du wirklich ein rumdum sorglos Paket willst, dann guck dir mbed OS an. Das kommt mit Treibern, aber die sind dann sehr basic. Die können nur das was alle unterstützen MCUs können.
Mw E. schrieb: > Wenn du wirklich ein rumdum sorglos Paket willst, dann guck dir mbed OS > an. Jepp, richtig. Leider fahren hier alle nur noch auf den zusammen gewürfelten Code ab :( Gut, bis auf die paar Hardliner die einen HAL gar nicht mögen.
Mw E. schrieb: > Wenn du wirklich ein rumdum sorglos Paket willst, dann guck dir mbed OS > an. Johannes S. schrieb: > Leider fahren hier alle nur noch auf den zusammen > gewürfelten Code ab Aus gutem Grund! Ein gelungenes HAL macht das Portieren von Code trivial. Zahlreiche Vorteile: Keine sorgen wegen MCU Obsolenz. Einfaches update der eigenen Produkte (kann immer der STM der neusten Generation verwedet werden). Z.Bsp. macht es heutzutage überhaupt keinen Sinn ein neues Produkt mit einem F3 oder F4 zu entwickeln, da der STM32F730R8T6 nur unwesentlich teurer ist. Die HAL Leute sollten gut lachen und können ihr F3,F4 Produkt einfach updaten haben und die Hardliner gucken in die Röhre... Auch verstehe ich ST nicht 700 verschidene STMs anzubieten... Wenn man den Produktionsprozess jeden Tag umstellt dauert es immer noch 2 jahre bis jeder ASIC einmal dran war. Eigentlich genügt ein kleiner <1Eur, ein der STM32F730R8T6 ein STM32F730R8T6 als 32 pin version sowie ein kleiner H7 sowie ein top H7 mit riesigem BGA.... 5 STMs anstelle 700! Diese könnten dann auch ordentlich supportet werden und der Cube wäre nicht mehr buggy...
STM32 schrieb im Beitrag #6010093: >> Wenn du wirklich ein rumdum sorglos Paket willst, dann guck dir mbed OS >> an. Danke für den Tipp! unterstüzt der den STM32F730R8T6 sowie den STM32H743VIT6? Gibts irgend ein kleines (vido) tutorial wie aufsetzen?
STM32 schrieb im Beitrag #6010103: > Gibts irgend ein kleines (vido) tutorial wie aufsetzen? https://os.mbed.com/docs/mbed-os/v5.14/quick-start/offline-with-mbed-cli.html https://github.com/ARMmbed/mbed-os-example-blinky Der F743 wird unterstützt, Targetname ist dann NUCLEO_H743ZI. Der F730 nicht, aber einige andere F7. Da Mbed für die ST intern auch den HAL benutzt ist eine Portierung aber nicht schwierig. Einen HAL finde ich auch ok, vor allem bei der großen Anzahl an Cortex-M µC die ST inzwischen auf dem Markt hat. Nur den Workflow mit dem Cube finde ich suboptimal. Du lässt dir ein Projekt generieren, soweit ok. Dann eigenen Code in den generierten einfügen. Jetzt möchtest du einen weiteren Timer, IO oder sonstwas. Dann wieder per Cube den Code modifizieren lassen. Wenn man dabei einen Fehler macht kann Cube den Code schreddern. Man kann natürlich z.B. GPIO einfach selber per Copy&Paste vervielfachen, aber dann weiß Cube nix davon. Der Cube sollte also immer der Master sein. Beim OS mit OO Ansatz mit Mbed ist das einfacher: eine DigitalOut Instanz kopieren, Pinnamen ändern, fertig. So lassen sich gut eigene Libs zusammenstellen die dann einfach in das nächste Projekt kopiert und wiederverwendet werden können. Aber CubeMX hilft hier trotzdem, wenn man eine Peripherie nutzen möchte die nicht vom OS unterstützt wird liefert Cube den nötigen Code. Da Mbed wie gesagt intern den HAL nutzt lässt sich der generierte Code einfach integrieren.
STM32 schrieb im Beitrag #6010093: > Auch verstehe ich ST nicht 700 verschidene STMs anzubieten... Wenn man > den Produktionsprozess jeden Tag umstellt dauert es immer noch 2 jahre > bis jeder ASIC einmal dran war. es wird pro Serie nicht so viele unterschiedliche Masken geben, ich kann mir z.b. vorstellen, dass alle F30x mit den gleichen Masken gefertigt werden, und die Halbleiter erst nach Test per Laser, OTP oder sonstwie auf einen bestimmten Typ "fixiert" werden. Chips mit Defekt im Flash verkauft man dann einfach als Typ mit weniger. Bei dem F103ern gibts welche wo dieser "zusätzliche" Flash-Speicher sogar verwendbar ist (soweit er halt funktionstüchtig ist).
STM32 schrieb im Beitrag #6010093: > Auch verstehe ich ST nicht 700 verschidene STMs anzubieten... Wenn man > den Produktionsprozess jeden Tag umstellt dauert es immer noch 2 jahre > bis jeder ASIC einmal dran war. Eigentlich genügt ein kleiner <1Eur, ein Soviele gibt's gar nicht. Viele Varianten enthalten den gleichen Die, das Flash-Size-Register anders programmiert, und schon hat man 3 oder gar 4 Varianten. Oder: Die G070 und G071 sind offensichtlich identisch, bis auf den anderen Aufdruck (und möglicherweise beim G070 einige ungetestete oder abgeschaltete Peripherie). H743 und H745 sind anscheinend auch identisch, beim H743 ist nur der M4 (irreversibel???) abgeschaltet. Aber die Preisdifferenz ... , Marketing halt.
STM32 schrieb im Beitrag #6010093: > Johannes S. schrieb: >> Leider fahren hier alle nur noch auf den zusammen >> gewürfelten Code ab > > Aus gutem Grund! Ein gelungenes HAL macht das Portieren von Code > trivial. Da gebe ich dir recht, aber der ST HAL ist nun alles andere als gelungen. Abstrahiert wird da nicht wirklich. Ein beispiel: Wenn du bei nem F4 was mit nem DMA machen willst, dann musst du DMA Stream und Channel wissen für das Configstruct. Eine tolle Abstraktion haben die da! Mein Eigenbau HAL ist jetzt schon von F2 zu F4 umgezogen ohne Änderungen. Es brauchte hier und da mal ein neuen Enumeintrag im RCC HAL (weil einfach mehr Peripherie vorhanden war). Beim F7/H7 muss der DMA Teil neu, aber der ist eben komplett anders. Dein Einstieg zu mbedOS hat dir ja schon wer anders reingereicht.
A. B. schrieb: > STM32 schrieb im Beitrag #6010093: >> Auch verstehe ich ST nicht 700 verschidene STMs anzubieten... Wenn man >> den Produktionsprozess jeden Tag umstellt dauert es immer noch 2 jahre >> bis jeder ASIC einmal dran war. Eigentlich genügt ein kleiner <1Eur, ein > > Soviele gibt's gar nicht. Viele Varianten enthalten den gleichen Die, > das Flash-Size-Register anders programmiert, und schon hat man 3 oder > gar 4 Varianten. Beim CubeMX werden im Ordner "db" Beschreibungsdateien für die ganzen Controller mitgeliefert. Da steht jeweils auch eine Die-ID drin. Da kann man ganz genau nachvollziehen welche Chips identisch sind.
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.