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.
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:> 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
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.
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
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.htmlhttps://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.
