Hallo Leute,
da im Netz aktuell noch keinerlei Infos bzw Fotos vom neuen STM32F7
Discovery Board zu finden sind, wollte ich euch diese hier nun zur
Verfügung stellen.
Es ist ein STM32F746NGH6 verbaut welcher mit 216MHz läuft.
(1MB Flash, 320kB RAM)
Ebenfalls verbaut ist ein:
- 4,3" WQVGA TFT LCD mit kapazitivem Touch
- 3x USB (FS/HS/ST-Link)
- RJ45 Ethernet
- Arduino Header
- µSD Karten Slot
- I/O Audio (3,5mm Klinkenbuchse)
- Kamerastecker (FFC)
- SPDIF (Cinch Buchse)
- 2x Mems Mikrofone
Richtpreis: ca. 50€
Rundum ein tolles Evalboard zum Herumspielen... :-)
Greets
Genau, habe den Preis auch von Digikey...
Das Board ist aktuell NOCH nicht verfügbar!
Sorry, hätte ich dazuschreiben sollen!
Ich habe es heute beim STM32F7 Hands-On Seminar in München erhalten...
Claus Mueller schrieb:> Interessantes Teil, danke für die Info! Allerdings finde ich keine> Bezugsquelle... Wo bekommt man denn dieses Spielzeug her?
Direkt beim Hands-on ;)
http://www.st.com/web/en/seminar/stm32f7-hands-on-seminars
Ergänzend zu oben: Verbaut sind u.a. ein N25Q128A (128 MBit, QSPI-Flash,
der F7 kann Code direkt aus diesem Flash ausführen...), ein SMSC 8742A
Ethernet Phy, Wolfson/Cirrus WM8994E Audio-Codec (4x 24-Bit DAC, 2x
24-Bit ADC) und ein MT48LC4M32B2B5-6A IT (D9NQQ Marking, 128 MBit SDRAM)
Danke für die Ergänzungen Arc Net!
Ich kann nur jedem empfehlen, der die Möglichkeit und das Interesse hat,
so ein Seminar zu besuchen. Es ist kostenlos, sehr informativ und man
erhält dieses Board gratis... ;-)
Anbei noch der Schaltplan vom F7 Discovery als PDF.
Greets
Hands on am 15. Juli in Frankfurt.
Sau blöd, dass ich da nicht hin komm...
Zu Fachfremd, ums geschäftlich abzuwickeln,
zu kurzfristig, um Urlaub zu beantragen. -.-
Was sind denn die Einsatzgebiete des cortex-m7?
Von der Peripherie her erinnert es an den Raspberry Pi und konsorten,
ohne vernünftiges Betriebssystem macht es aber wahrscheinlich keinen
Spass auf dem M7 zu arbeiten.
Der M7 ist ein deutlich aufgebohrter M4. Höhere Taktung, effizientere
Speicheranbindung, mehr Peripherie, etc...
Ein Rasp-Konkurrent ist es definitiv nicht, denn der hat völlig andere
Einsatzgebiete.
Der M7 hat internes Flash, was der Rasp nicht hat. Das bremst die
CoreClock deutlich runter (Aufgrund verschiedener
Fertigungstechniken)(200MHz auf M7 vs 1GHz auf Rasp). Auch fehlt DDR RAM
unterstützung.
Allgemein ist der Rasp für Multimedia, der M7 für embedded Applikationen
und Industrie-Anwendungen
(Bitte korrigieren, wenn ich völligen Bullshit erzähle!)
Little Basdart schrieb:> Allgemein ist der Rasp für Multimedia, der M7 für embedded Applikationen> und Industrie-Anwendungen>> (Bitte korrigieren, wenn ich völligen Bullshit erzähle!)
Ja, so in etwa. Der M7 ist ein Mikrocontroller-Kern und hat als solcher
vor allem ein wesentlich besseres Interrupt-System. Und der
Stromverbrauch ist in einer ganz anderen Groessenordnung, was aber bei
solchen Evalkits relativ ist, da die Peripherie den Grossteil aufnimmt.
Operator S. schrieb:> Was sind denn die Einsatzgebiete des cortex-m7?> Von der Peripherie her erinnert es an den Raspberry Pi und konsorten,> ohne vernünftiges Betriebssystem macht es aber wahrscheinlich keinen> Spass auf dem M7 zu arbeiten.
Peripherie:
Siehe Datenblatt:
In Bezug auf Automatisierungstechnik ist der M4 / M7 Kern einem Rasberry
PI deutlich überlegen das diese eben im PI nicht vorhanden.
Ich sehe den Controller eher als Kommunikationspartner zur "nachsten
"Ebene" Also Datenaustausch mit dem PI , etwa über USB Ethernet.
Betriebssystem: Beispiel FreeRTOS
Danke für die Infos. Schaut auf jeden Fall nach einem tollen board aus.
Das einzige was nicht stören könnte ist, dass scheinbar kaum freie I/O
raus geführt sind also die Nutzung des boards für eigene Projekte etwas
limitiert ist. Die Pinleisten unten erinnern mich stark an Adrduino?
STM32 USER schrieb im Beitrag #4176076:
> Danke für die Infos. Schaut auf jeden Fall nach einem tollen board aus.> Das einzige was nicht stören könnte ist, dass scheinbar kaum freie I/O> raus geführt sind also die Nutzung des boards für eigene Projekte etwas> limitiert ist. Die Pinleisten unten erinnern mich stark an Adrduino?
Ja, ist ein Ardino-Header...
Für freie I/Os dürfte das Board nicht gemacht sein, ich würde es als
Spielplatform ansehen um die Möglichkeiten der neuen Controller zu
erkunden.
Über Betriebssysteme wurde dort eigentlich gar nichts gesagt. Lediglich
beim CubeMX Hands-on wurde die Middleware (FreeRTOS, usw) kurz
angesprochen...
Wir haben ein kleines Test-Projekt mit dem CubeMx für das F7 Discovery
angelegt und es funktioniert schnell und gut.
Ich persönlich kann mich aber noch nicht ganz damit anfreunden, dass mir
das Tool mein Projekt und den Init Code etc erstellt, auch wenn es an
und für sich sehr komfortabel ist...
Little Basdart schrieb:> Hands on am 15. Juli in Frankfurt.>> Sau blöd, dass ich da nicht hin komm...> Zu Fachfremd, ums geschäftlich abzuwickeln,> zu kurzfristig, um Urlaub zu beantragen. -.-YAY
Ich darf hin! Ich griegs als Weiterbildung bezahlt, muss nur die
Fahrtkosten tragen freu
Torsten C. schrieb:> Geht das gut, oder nervt das eher?
Es kommt auf die IDE Plattform an.
Für kostenlose IDE, etwa CooIDE ist nacharbeiten angesagt, das kann
nerven.
Das Problem sehe ich hierbei aber eher be der Zielplattform.
CooIDE fügt (bei mir) die Cube Bibliotheken 2 mal ein.
Und die Sourcen welches das Cooide Template und das Cube Template
erzeugt gibt es abermals Überschneidungen.
Andererseits:
Die zusammenarbeit von Cube und "passender" IDE, etwa IAR klappt
ziemlich nahtlos.
Hallo,
Wie läuft so ein Seminar ab?
In Form eines Vortrages?: (d. h. in einem größen Saal steht eine Person
in der Mitte und berichtet mit Hilfe von Beamer, was sie so tolles
entworfen haben)
oder eher in einer Gruppe mit 15-20 Leuten?
Gibt es da irgenwelche Voraussetzung (Skill) für die Teilnahme?
Danke
mfg. Christian
Jo würde mich auch interessieren .
Wann bekommt man das F7 board , erst nach dem Seminar oder schon vorher
und was ist wenn ich da ohne Anmeldung erscheine ?
MfG , Thomas C.
Ja, es ist quasi ein Vortrag mit Beamer, jedoch mit diversen Übungen.
In München haben daran ca. 40 Personen teilgenommen.
Man MUSS sich vorher anmelden und auf die Bestätigungsmail abwarten da
die Teilnahme begrenzt ist. Es wird aber nichts vorausgesetzt...
Das Discovery bekommt man gleich am Anfang.
Jeder Teilnehmer nimmt seinen eigenen Laptop mit und muss alle
notwenigen Tools vorinstallieren (CubeMx, IAR usw).
Es wechselt sich dann immer Theorie und Praxis ab, wobei die Praxis
meist aus vorgefertigten Projekten besteht die man dann einspielt und
testet.
Außer bei einer Übung musste man alles selbst erstellen, jedoch mit
guter Anleitung als PDF bzw Beamer (also mit CubeMx das Projekt und die
Peripherie und dann noch etwas C Code ergänzen und testen).
Ach ja, es gibt Kaffee und Kuchen in den Pausen sowie ein Mittagessen
für lau... ;-)
Greets
>Der M7 hat internes Flash, was der Rasp nicht hat. Das bremst die>CoreClock deutlich runter (Aufgrund verschiedener>Fertigungstechniken)(200MHz auf M7 vs 1GHz auf Rasp). Auch fehlt DDR RAM>unterstützung.
Waitstates nicht vergessen.
John W. schrieb:> Jeder Teilnehmer nimmt seinen eigenen Laptop mit und muss alle> notwenigen Tools vorinstallieren (CubeMx, IAR usw).
Und USB-Kabel ;) Einmal Mini-USB für das eingebaute ST-Link und einmal
Micro-USB für die Kommunikation mit dem Controller. In Dortmund hatten
die Veranstalter genügend Leihkabel mitgebracht.
> Außer bei einer Übung musste man alles selbst erstellen, jedoch mit> guter Anleitung als PDF bzw Beamer (also mit CubeMx das Projekt und die> Peripherie und dann noch etwas C Code ergänzen und testen).
Wahrscheinlich auch das Scope-Projekt, oder? Da gab's je nach OS
durchaus Probleme mit dem CDC-Treiber. Ansonsten gefällt mir die
CubeMX-Software mittlerweile ganz gut (nutze die auch in einem Projekt
mit dem STM32F411).
Es gibt imo bessere (SiLabs Precision32 oder Cypress PSoC) Tools, finde
CubeMX aber deutlich benutzbarer als die "Tools" so manch anderer
Hersteller.
Was mir fehlt ist bspw. die Unterstützung verschiedener Betriebszustände
wie bei SiLabs- oder Microchips-Tools.
Zu den IDEs gab's noch die Info, dass auch an Linux-Unterstützung
gearbeitet wird (Ac6 / OpenSTM32.org, System Workbench, die auf Eclipse
basiert).
CubeMX läuft unter Linux, nur die Installation ist z.Z. noch etwas
Handarbeit
(http://fivevolt.blogspot.de/2014/07/installing-stm32cubemx-on-linux.html)
Seit geraumer Zeit versuche ich den im STM32F746G-DISCO Board
verwendeten
kapazitiven Touch Controller zu identifizieren.
Ich finde hierzu nichts im User Manual (UM1907) oder im Schematic.
Das Display kommt von RockTech, unter der im Schematic angegebenen
Bezeichnung gibt es bei denen nichts direkt - zumindest nichts zum
verwendeten Touch Controller.
In der aktuellen STM32CubeF7 Firmware gibt es Hinweise auf versch. Touch
Controller (TS3510(?)/ MFXSTM32L152(?)/...), diese bringen mit Google
keine brauchbaren Ergebnise.
Weiß jemand was genaueres zu dem im Display verbauten Touch Controller?
Kann man an diesem Seminar auch als Hobbyist teilnehmen oder ist das nur
für Leute gedacht, die berfulich damit zu tun haben?
John W. schrieb:> Jeder Teilnehmer nimmt seinen eigenen Laptop mit und muss alle> notwenigen Tools vorinstallieren (CubeMx, IAR usw).
Kann auch die Evaluationcopy von IAR verwendet werden?
Wenn man sich bei ST anmelden will, wird nach einem Firmennamen gefragt.
Ich habe meinen Fake-Firmennamen eingetragen, mit dem ich vieleicht
irgendwann in ferner Zukunft ein Gewerbe anmelden werde.
Beim Anmelden zu diesem Seminar werden die Standard Angaben verlangt,
wie es auch bei Sample-Bestellungen üblich ist:
- In welchem Busines ist man tätig
- Welche Funktion hat man in der Firma
- Wie weit ist das Projekt, für das dieser Chip/Seminar benötigt wird
- Jährliche Stückzahlen, Start der Produktion
Weil hier einige nach RTOS gefragt haben: SEGGER embOS läuft da auch
schon drauf. Das Startprojekt für das ST STM32756G-Eval läuft auch auf
dem Discovery.
https://segger.com/embos-cortexm-iar.html
Uwe B. schrieb:> Hat jemand eine Registerbeschreibung zum verwendeten Rockteck> RK043FN48H-CT672B Display?
Danke für die Frage ;-)
Warum wird kein passives Standard-Display mit resistivem Touch genommen,
welches keine internen Register braucht/hat?
Ein LCD-Controller ist doch vorhanden, und die touch-Auswertung könnte
der interne ADC oder, wenn es unbedingt sein muß, ein extra Controller
übernehmen. Beim F429-Disco war das TFT ja auch schon gurkenmäßig
angeschlossen.
Ich seh schon, doch wieder Alles selber machen ;-)
m.n. schrieb:> ... und die touch-Auswertung könnte der interne ADC ...
Nein - kann er nicht ;) -> es ist ein kapazitiver Touch.
Auf dem F7-Board kommen nur noch I2C Signale (ich meine nicht die
TFT-Steuersignale wie VSYNC/ HSYNC, ...) an, daher vermute ich, das der
Touch Controller auf dem TFT-Board sitzt.
Aber welcher?
Uwe N. schrieb:> Nein - kann er nicht ;) -> es ist ein kapazitiver Touch.
Mein Konjunktiv bezog sich auf einen resistiven Touch ;-)
Oder anders ausgedrückt: es könnten auch diverse andere TFTs (z.B. 800 x
480) angeschlossen werden, ggf. mit etwas geänderter Verdrahtung.
m.n. schrieb:> Mein Konjunktiv bezog sich auf einen resistiven Touch ;-)
Ok :)
Aber ich habe auch nix gegen einen kapazitiven Touch, das hatte ich
bisher noch nicht. Und da STemWin nun auch Mult-Touch unterstützt
(v.5.28) wäre das eine gute Gelegenheit hier mal reinzuschnuppern.
Ja, auch Wischbewegungen machen bei resistivem Touch keinen Spaß.
Aber wie auch bei vielen anderen DISCOs sind viele Pins belegt. Das
nervt!
Bei meinem STM32F4 DISCO kriege ich den DAC z.B. nicht unter 200mV. :-(
Ein STM32F7 NUCLEO muss her!
Uwe B. schrieb:> Damit wir es wohl kaum ein Nucleo geben...
Namen sind ja nur Schall und Rauch.
Das habe ich auch gelesen. Dann sollen die halt eine dritte Stiftleiste
daneben machen oder die doppelreihigen Stiftleiste verlängern oder …
Was ich damit sagen will: Ein STM32F7 ohne Demo-Peripherie muss her!
Torsten C. schrieb:> Bei meinem STM32F4 DISCO kriege ich den DAC z.B. nicht unter 200mV. :-(
Arbeitest Du mit dem internen Pufferverstaerker? Jeder Verstaerker hat
Probleme wenn er nahe an seinen Versorgungsspannungen treiben soll.
Betreibe den DAC ohne den Puffer und setzte eine externen Puffer mit
"etwas" negativer Versorgung, z.B. durch den LM7705 dran. Dann solltest
Du bis ggf. auf den DAC Offset an Null herankommen.
Uwe B. schrieb:> Arbeitest Du mit dem internen Pufferverstaerker?
Was meinst Du mit 'intern'?
Ich habe nur ein Oszi am Ausgang.
An PA4 = P1.16 stört offenbar CS43L22 LRCK und
an PA5 = P1.15 stört offenbar LIS302DL SCL/SPC
Torsten C. schrieb:> Was ich damit sagen will: Ein STM32F7 ohne Demo-Peripherie muss her!
Was bringt Dir fuer den Anfang ein nackter F7? Brauchst Du nur mehr
Speed, dann mag er sinnvoll sein. Aber wenn du neue Peripherie auf eine
neuen Baustein in eine neun Design verwendest, dann hast Du sehr viele
offene Enden.
Uwe N. schrieb:> Weiß jemand was genaueres zu dem im Display verbauten Touch Controller?
Zum STM32F7-Discovery:
Die Materialien, die es beim Hands-on gab, enthalten im BSP
(Drivers/BSP/Components) die Quelltexte zur Ansteuerung der genannten
ICs, die laut Copyrightvermerk weitergegeben werden dürften.
MFXSTM32L152 ?= STM32L152 mit Peripherie zur Kapazitätsmessung
http://www.st.com/web/catalog/mmc/FM141/SC1544/SS1374/LN1041/PF248824?sc=internet/mcu/product/248824.jsp
FT5336 = cap. touch controller
http://www.focaltech-systems.com/En/index.aspx
Datenblatt = Gute Frage...
TS5310 = auch cap. touch, ansonsten keine Infos auffindbar
STMPE811 = res. Touch, Application Note bei ST auffindbar
EXC7200 = cap. touch von EETI
Zu den Displays sind dort nur Header-Files mit den Timings dabei.
Für die Grafikfunktionen wurde ansonsten STemWin genutzt (das gibt's
zwar kostenlos, allerdings nur in Binärform)
http://www.st.com/web/en/catalog/tools/PF259225
Autor: Torsten C. (torsten_c) schrieb:
>Bei meinem STM32F4 DISCO kriege ich den DAC z.B. nicht unter 200mV. :-(
Dann stimmt was ned.
Bei mir gingen beim Testen vor zwei Wochen beide Kanäle auf dem 407
Disco wie sie sollen. Auch sagt das Datenblatt, daß die Spannung
lediglich von V_ref *n/4095 abhängt. Biste sicher das nicht irgendein
schwacher Pullup aktiv ist oder Open-Drain oder hardwärmäßig irgendwas
im Argen liegt?
Nebenbei: Der AT91SAM3X8E (Arduino Due) hat diese Einschränkung
tatsächlich - der Spannungsbereich reicht nur von 1/6 ... 5/6 V_ref.
Gaaanz hinten, bei den Specs ist's irgendwo in einer Zeile vermerkt,
sonst nirgends. Hat der Chip-Designer wohl ein schlechtes Gewissen
wegen.
Torsten C. schrieb:> Uwe B. schrieb:>> Arbeitest Du mit dem internen Pufferverstaerker?>> Was meinst Du mit 'intern'?>
RM0090: 14.3.2 DAC output buffer enable
Datenblatt STM32F405: 5.3.24 DAC electrical characteristics
Vmin ist 0.2 V mit "buffer ON"
Uwe B. schrieb:> Vmin ist 0.2 V mit "buffer ON"
Oh mann! Danke! Wer lesen kann, ist klar im Vorteil.
> The buffer can be bypassed by configuring the BOFFx bit in the> DAC_CR register.
:-)
Das werde ich dann mal so machen.
Ich dachte bis eben, es liegt an dieser hyperliquiden Peripherie
(CS43L22 und LIS302DL).
Arc N. schrieb:> Uwe N. schrieb:>> Weiß jemand was genaueres zu dem im Display verbauten Touch Controller?> Zum STM32F7-Discovery:> Die Materialien, die es beim Hands-on gab, enthalten im BSP> (Drivers/BSP/Components) die Quelltexte zur Ansteuerung der genannten> ICs, die laut Copyrightvermerk weitergegeben werden dürften.> MFXSTM32L152 ?= STM32L152 mit Peripherie zur Kapazitätsmessung> http://www.st.com/web/catalog/mmc/FM141/SC1544/SS1374/LN1041/PF248824?sc=internet/mcu/product/248824.jsp> FT5336 = cap. touch controller> http://www.focaltech-systems.com/En/index.aspx> Datenblatt = Gute Frage...> TS5310 = auch cap. touch, ansonsten keine Infos auffindbar> STMPE811 = res. Touch, Application Note bei ST auffindbar> EXC7200 = cap. touch von EETI> Zu den Displays sind dort nur Header-Files mit den Timings dabei.> Für die Grafikfunktionen wurde ansonsten STemWin genutzt (das gibt's> zwar kostenlos, allerdings nur in Binärform)> http://www.st.com/web/en/catalog/tools/PF259225
Danke für die Info - ich hatte bei meiner Suche ähnliche Ergebnisse.
Also d.h. im ungünstigsten Fall muss man per Trail & Error Verfahren die
richtigen Treiber rausfinden...
Ich hoffe, das ST hier nochmal mehr Infos rausrückt.
Arc N. schrieb:
> Uwe N. schrieb:>> Weiß jemand was genaueres zu dem im Display verbauten Touch Controller?
Laut Schaltplan ist als Display ein RK043FN48H-CT672B der Firma Rocktech
Displays Limited eingebaut. Auf der Rocktechseite steht dann beim
Display RK-CTP-043B672A mit kapazitiven Touchscreen: Controller
FT5336GQQ. Leider ist genau dieser nicht im Treiberpaket
STM32Cube_FW_F7_V1.0.0 enthalten. Vieleicht kann den ja mal jemand hier
reinstellen.
m.f.G.
Dieter
Dieter Graef schrieb:> Controller FT5336GQQ. Leider ist genau dieser nicht im Treiberpaket> STM32Cube_FW_F7_V1.0.0 enthalten. Vieleicht kann den ja mal jemand hier> reinstellen.
Die Release-Notes sprechen zwar von Version 0.0.1 non-official release,
allerdings mit normaler Lizenz: "Redistribution and use in source and
binary forms, with or without modification, are permitted provided that
the following conditions are met:" daher siehe Anhang.
Little B. schrieb:> Der M7 hat internes Flash, was der Rasp nicht hat. Das bremst die> CoreClock deutlich runter (Aufgrund verschiedener> Fertigungstechniken)(200MHz auf M7 vs 1GHz auf Rasp). Auch fehlt DDR RAM> unterstützung.
Naja, das liegt bei ST an der Uralttechnik. Die nutzen noch den
gammeligen 90nm-Prozess. Bei der Konkurrenz von Atmel oder Freescale
wird das anders sein, so dass die sicherlich mindestens bis 400MHz gehen
werden.
Enttäuschend auch, daß die FPv5 nicht implementiert ist (also doppelte
Float-Genauigkeit).
Hoffentlich kommt die Konkurrenz nem ordentlichen M7 zum selben Preis
für ein Eval-Board bald an den Start ;)
Uwe N. schrieb:> Danke für die Info - ich hatte bei meiner Suche ähnliche Ergebnisse.> Also d.h. im ungünstigsten Fall muss man per Trail & Error Verfahren die> richtigen Treiber rausfinden...
Für mich ein Grund, nicht der Panik mit immer schneller, weiter, höher
zu erliegen, sondern das zu nutzen, was vorhanden ist und läuft und
preiswerter ist. Und damit meine ich die STM32F4xx.
Zum 'Herumspielen' kommt das Demo-Board sicherlich eines Tages auf den
Tisch.
Aber egal wieviel schneller der F7 auch sein mag, man kommt immer an den
Punkt, wo die gebotene Leistung nicht reicht ;-)
Noch ein paar Infos:
Über den Mini-USB hat man zusätzlich zum Debugger (SWD) einen Virtuellen
COM Port (ist mit USART1 des F7 verbunden) und ein Mass Storage Device
(EmBed Flashdisk ?)
Der F7 ist pinkompatibel zum F4 (bis auf das 100 Pin Gehäuse). Mit der
Softwareportierbarkeit schaut es aber nicht so gut aus. Es wird keine
Standard Peripher Lib für den F7 geben. F4 Projekte die die SPL
verwenden müssten auf Qube umgeschrieben werden!
Auf der Mauser Seite
http://www.mouser.de/new/stmicroelectronics/stm-stm32f7-mcu-fpu/
wird erwähnt, dass vom 128MBit SDRAM nur 64MBit verfügbar sind (?)
Die Doku beschränkt sich auf das Datasheet, Reference Manual und
Schaltplan des Discovries.
Wie auf den Fotos zu sehen, sind die Discovery typischen Stiftleisten
nicht mehr vorhanden, was das Messen von Signalen und den
Prototypenaufbau eigener Hardware deutlich erschwert.
CooCox kann momentan nicht verwendet werden. Wenn, dann kommt es sicher
nur in der (ungeliebten) 2er Testversion und nach den Erfahrungen des
429 Discos nicht in diesem Jahr (hoffentlich ist UB wieder schneller :)
OpenSTM32 ist zwar schon in Qube integriert, hakt aber doch öfter mal.
Spätestens nach den 30 Testtagen der IAR IDE werde ich aber damit
arbeiten.
Für mich war die Erklärung der Caches und superskalaren Architektur
anhand von Benchmarks das interessanteste am Seminar. So kann man Code
aus dem Quad-SPI Flash quasi ohne Waitstates (im besten Fall) ausführen.
Allerdings kann man auch erreichen, dass der F7 langsamer als der F4
wird (bei selben C Code).
Das Debugging wird durch die komplexere Struktur eine Herausforderung
und die Entwicklungsumgebungen sind wohl noch nicht für die neuen
Features ausgelegt. Was passiert z.B. wenn ich einen Breakpoint auf eine
Assemblerinstruktion setzte, zur Laufzeit aber zwei Instruktionen
parallel ausgeführt werden und die parallel ausgeführte Instruktion das
Ergebnis der ersten verändert?
Fazit der F7 ist deutlich komplexer als der F4 und wird bei mir erst mal
nicht in kommerziellen Projekten eingesetzt (habe zur Zeit aber auch
keinen Leistungsengpass).
Trotzdem freue ich mich über das schöne neue Spielzeug und sehe mich
schon einige Abende mit rauchendem Kopf davor sitzen...
Pet Heg schrieb:
>wird erwähnt, dass vom 128MBit SDRAM nur 64MBit verfügbar sind (?)
dem Schaltplan nach wurde ein SDRAM mit 32Bit Datenbus eingebaut von dem
aber nur 16 Bit verwendet werden.
Dieter Graef schrieb:> Controller> FT5336GQQ. Leider ist genau dieser nicht im Treiberpaket> STM32Cube_FW_F7_V1.0.0 enthalten.
Danke Dieter. Leider ist auch dieser offenbar nicht als Datenblatt
auffindbar. Arg...
m.n. schrieb:> Für mich ein Grund, nicht der Panik mit immer schneller, weiter, höher> zu erliegen, sondern das zu nutzen, was vorhanden ist und läuft und> preiswerter ist.
Naja, ich verfalle nicht gleich in Panik :)
Mein interesse an dem Board kommt daher, das ich gerade eine eignes
STM32F4
Board bauen wollte, da das F429er Disco leider nur über ein arg kleines
Display verfügt. Nun kündigt sich ein neues und gut ausgestattetes Board
mit einem 4.3" TFT und eben einen neuen Prozessor an.
Für ca.50€. Da kann ich einfach nicht widerstehen :)
Uwe N. schrieb:> Mein interesse an dem Board kommt daher, das ich gerade eine eignes> STM32F4> Board bauen wollte, da das F429er Disco leider nur über ein arg kleines> Display verfügt.
Das geht mir doch genau so ;-) Vieles wurde ja schon hier besprochen:
Beitrag "Bedarf an eigenbau STM32F429 Evaluation Board ?"
Wenn es konkret wird, driften die Vorstellungen aber mehr oder minder
weit auseinander.
Für den F407 habe ich eins mit 5,7" TFT, was als Bedienteil fungiert,
aber minimal weitere I/O-Anschlüsse nach außen führt. Für ein 4,3" habe
ich das Layout fast fertig und werde da wohl einen F427 draufpacken. Da
aber aktuell keine Stückzahl in Sicht ist, möchte ich mir die Arbeit
nach Möglichkeit sparen; das ist dann eher etwas für den Winter.
m.n. schrieb:> Vieles wurde ja schon hier besprochen:> Beitrag "Bedarf an eigenbau STM32F429 Evaluation Board ?"> Wenn es konkret wird, driften die Vorstellungen aber mehr oder minder> weit auseinander.
Ja, genau das war hier auch das "Problem" meinerseits. Ich hatte
überlegt, mir ein Board bei Uwe B. zu ordern. Leider gefiel mir
schlussendlich der Aufbau mit den getrennten Boards für µC und TFT gar
nicht.
Ich werde also erstmal mit dem STM32F7xx DISCO herumspielen (so es denn
irgendwann mal lieferbar ist) und mein eignes Disco-Board ebenfalls in
die langen und kalten Winterabende verlegen :)
So - kleine Info für alle die es interessiert:
Bei DigiKey sind aktuell ein paar Boards auf Lager :)
Meins ist unterwegs - wenn kein Streik dazwischen kommt...
Pet H. schrieb:> Der F7 ist pinkompatibel zum F4 (bis auf das 100 Pin Gehäuse).
Aber nicht 100%.
> Mit der> Softwareportierbarkeit schaut es aber nicht so gut aus. Es wird keine> Standard Peripher Lib für den F7 geben. F4 Projekte die die SPL> verwenden müssten auf Qube umgeschrieben werden!
Auch der Cube ist nicht 100% kompatibel. Bei I²C musste ich ein paar
kleine Änderungen machen. Ich habe jetzt aber nicht ins Datenblatt
geschaut, ob das vielleicht auf Hardwareänderungen beruht.
> Das Debugging wird durch die komplexere Struktur eine Herausforderung> und die Entwicklungsumgebungen sind wohl noch nicht für die neuen> Features ausgelegt. Was passiert z.B. wenn ich einen Breakpoint auf eine> Assemblerinstruktion setzte, zur Laufzeit aber zwei Instruktionen> parallel ausgeführt werden und die parallel ausgeführte Instruktion das> Ergebnis der ersten verändert?
Sowas geht? Ich war immer der Ansicht, dass parallel ausgeführte
Instruktionen keine Abhängigkeiten untereinander haben dürfen. So ganz
allgemein, nicht nur beim M7.
Kleiner Tipp am Rande: ARD_D5 und ARD_D10 sind im Schaltplan vertauscht.
Merkt man wenn man die Timer benutzt um eine Kamera zu emulieren...
(Teilnehmer des Dortmunder Workshops)
Pet H. schrieb:> Die Doku beschränkt sich auf das Datasheet, Reference Manual und> Schaltplan des Discovries.
Muss mich korrigieren, unter www.st.com/stm32f7-discovery gibt es ein
ausführliches User-Manual.
Habe heute morgen die Zusage für das Handson in Frankfurt erhalten. In
zwei wochen grieg ich das Board für umme, zusammen mit einem bezahlten
Arbeitstag ^^
Meins ist ebenfalls eingetroffen.
Mir scheint, das der F7 ein kleiner Hitzkopf ist - er wird recht warm.
Und das, obwohl die "CPU Last" nur ca.2% beträgt (Werksdemo).
ST sollte die M7 in 65nm oder 40nm fertigen lassen...
6a66 schrieb:> Daraus: Es soll einen STM32F745 ohne LCD geben - wenn man das googelt> kommt man zwar zu einem STM-Link aber der ist tot.
Aaaaaah, schon wieder nicht richtig gelesen :( Das Datenbtall hat den ja
auch schon.
rgds
Interessantes Board. Man kann es sogar für mbed.org verwenden. Leider
wurden nur sehr wenige GPIO´s nach Außen geführt und CAN ist auch nicht
verfügbar.
Hmm,
Ich warte noch auf den STM32F7 mit 2MB internem Flash, damit möchte ich
den STM32F429 ersetzen, den ich nur mit 168MHz Takten kann, da sonst der
FS USB nicht mehr läuft. Beim F7 sollen die internen Takte ja freier
verwendbar sein…
welche kostenlose Toolchain gibt es den im Moment für den M7 ?
so wie ich das sehe nur Attolic
oder mit einschränkungen (IAR und KEIL)
Ich habe Eclipse+Gcc+OpenOCD für den F407 und den F429 benutzt ...
welche Files müsste man für den F746 anpassen ?
Martin K. schrieb:> Hmm,>> Ich warte noch auf den STM32F7 mit 2MB internem Flash, damit möchte ich> den STM32F429 ersetzen, den ich nur mit 168MHz Takten kann, da sonst der> FS USB nicht mehr läuft. Beim F7 sollen die internen Takte ja freier> verwendbar sein…
Warum so grossen interner Flash? Was spricht gegen QSPI?
Uwe Bonnes schrieb:> Martin K. schrieb:>> Hmm,>>>> Ich warte noch auf den STM32F7 mit 2MB internem Flash, damit möchte ich>> den STM32F429 ersetzen, den ich nur mit 168MHz Takten kann, da sonst der>> FS USB nicht mehr läuft. Beim F7 sollen die internen Takte ja freier>> verwendbar sein…>> Warum so grossen interner Flash? Was spricht gegen QSPI?
Kommt drauf an. Bis auf die SPI-Flash-ICs von SST/Microship und die
seltenen SPI-Nands (Gigadevice/Winbond) sind die Teile beim Löschen und
Schreiben grottenlangsam.
Was aber bei der Codeausführung aus dem Flash eher keine Rolle spielen
dürfte, eher die Tatsache, dass der Code unverschlüsselt und einfach
auslesbar in so einem externen Teil steht.
schon beeindruckend wie sehr auf den M7 gewartet wird.
Das Ding ist mit 485DMIPS mehr als doppelt so schnell asl ein STM407 mit
168Mhz (210DMIPS).
Mir gefällt dass das Ding seinen eigenen Display controller für TFT's
besitzt und soweit ich das sehen konnte wohl auch HDMI kann.
Jedenfalls ist der Cortex-M7 von ST schon ordentlich schnell für einen
MC. Das Dico-Board ist wirklich für die Nutzung von Arduino-Shields
gebaut. Jedenfalls bleiben nicht wirklich viele Pin's übrig da das
Pinout des BGA-Chips wohl eine geringre Anzahl von Portpins verwendet
und die ON-BOARD Peripherie schon recht viel Pins belegt. Das DRAM
benötigt mit dem DISPLAY schon ordentlich PIN's. Dafür bekommt man ein
on.Board Ethernet mit Media-Controller und MAG-JACK.
ST macht schon richtig Radau auf dem MC-Markt. ATMEL's Cortex-M Politik
kann ich nicht nachvollziehen. Zu teuer und zu wenig Power.
Warten wir mal ab was alles in den kommenden Wochen von ST erscheinen
wird. Das Board wird so um die €50.- kosten. Ob es dabei bleiben wird,
bleibt abzuwarten. Das 4.3" Display mit kapazitiven Touch wird
sicherlich den Preis oberhalb von €40.- halten. Es ist sicherlich ein
interessantes Board. Schaun wir mal was andere noch so mit dem M7 von ST
bauen werden.
Juppeck schrieb:> schon beeindruckend wie sehr auf den M7 gewartet wird. ...> ...Das Board wird so um die €50.- kosten. Ob es dabei bleiben wird,> bleibt abzuwarten. ...
Das Teil kannst du seit kurzem kaufen - ich habe meines seit einigen
Tagen.
Und es kostet je nach Distri zw.45€ und 51€. Fairer Preis.
Juppeck schrieb:> ...und soweit ich das sehen konnte wohl auch HDMI kann.
Nein - kein HDMI. Nur CEC.
https://de.wikipedia.org/wiki/Consumer_Electronics_Control
Juppeck schrieb:> ATMEL's Cortex-M Politik> kann ich nicht nachvollziehen. Zu teuer und zu wenig Power.
Was meinst Du mit zu wenig Power? Der SAMS70/E70/V71 sind die
leistungsfähigsten CortexM7 auf dem Markt, beginnen derzeit bei 300MHz,
haben 2x soviel Speicher als vergleichbare STM32F7 und sind dazu noch
billiger. Selbst ST gibt den 1000St. Preis ab ca. 6.8$ an, für diesen
Preis bekommst Du bei Atmel 2x soviel Speicher.
Als Bsp bei Mouser:
STM32F746 100pin 1MB flash = 12.47Euro / 50St.
SAME70N20 100pin 1MB flash = 10.52Euro / 50St.
Der SAMV71 wird auch aus gutem Grund als Referenzplatform für DSP Audio
genommen, z.b DSPConcept oder von Qualcomm
https://www.semiwiki.com/forum/content/4607-what-real-samv71-dsp-performance-auto-audio.html
Alleine das Evalboard ist mit 129Euro etwas teurer, damit kannst Du aber
wesentlich mehr machen als nur die MCU zu evaluieren wie es mit dem
Disco der Fall ist. Wenn Du mit ST richtig entwickeln willst und dafür
ein Evalboard brauchst welches auch geeignet ist, dann kostet Dich der
Spaß über 500Euro für das STM32746G-EVAL2
der Anfang ist gemacht, ein LED Blinky für den STM32F7
Und wie weit seit ihr ?
Gruß,
dasrotemopped.
PS : mit dem ST-Link Utility V3.6.0 ins Board flashen ...
Juppeck schrieb:> Das Board wird so um die €50.- kosten. Ob es dabei bleiben wird,> bleibt abzuwarten.
Ich gehe davon aus, dass von dem Board >10kpcs kalkuliert sind. Der
Preis von etwa 50EUR ist aber dann wirklich auf Kante genäht.
BTW: Das Board ist in Frankreich entwickelt, ist ein 8-Lagen finpitch
PCB.
rgds
6a66 schrieb:> Der> Preis von etwa 50EUR ist aber dann wirklich auf Kante genäht.
War doch schon auch bei den M3/M4 Discoverys so.
Die werden wahrscheinlich nichts dabei verdienen, im Zweifelsfall sogar
drauflegen. Aber wenn man das Gesamtbild betrachtet ist das sehr gutes
Marketing, besser kann man es eigentlich fast nicht machen.
6a66 schrieb:> BTW: Das Board ist in Frankreich entwickelt, ist ein 8-Lagen finpitch> PCB.
Interessant, für den Nachbau läßt dieser Umstand Bastlers Herz
sicherlich höher schlagen ;-)
Stefan schrieb:> Der SAMS70/E70/V71 sind die> leistungsfähigsten CortexM7 auf dem Markt, beginnen derzeit bei 300MHz,> haben 2x soviel Speicher als vergleichbare STM32F7 und sind dazu noch> billiger.
Auch interessant, da die FPU auch 'double' rechnet. Aber einen
TFT-Controller habe ich bei den "billigeren" Teilen (SAME70) nicht
gesehen, was (mir) auch egal ist. Ob die vorhandene Leistung auch
benötigt/genutzt wird, hängt von den eigenen Anforderungen ab.
Das STM32F7-Disco wird hierzulande ja für rund € 45,-- netto angeboten.
Das ist wenig Geld, aber die Arbeit, es in Betrieb zu nehmen wäre mir
ohne konkrete Aufgabe noch zu teuer. Irgendetwas mit Cube(-Ka..e)
zusammenzuklicken, ist doch keine Lösung.
Aber ein Blinky scheint es ja schon zu geben ;-)
>aber die Arbeit>Irgendetwas mit Cube(-Ka..e) zusammenzuklicken, ist doch keine Lösung.>Aber ein Blinky scheint es ja schon zu geben ;-)
mit Keil 32k und Cube in 30 min zusammengehackt.
Lohnt also doch wenn man sich keine Arbeit machen will ...
Gruß,
dasrotemopped.
PS : der geneigte Bastler kann sich sein STM32F7-Board mit
TQFP in 4 Lagen bauen, vielleicht mit 7" Display wegen Platz und so.
dasrotemopped schrieb:> PS : der geneigte Bastler kann sich sein STM32F7-Board mit> TQFP in 4 Lagen bauen, vielleicht mit 7" Display wegen Platz und so.
Was wollt Ihr denn noch so draufhaben? :)
rgds
Mein Board mit dem STM32F746BGT6 ist fertig und in Produktion
Rohleiterplatten )
64 MB SDRAM ( 2 x 32MB )
Ethernet MII
USB-OTG FS
SPI-Flash 8MB
SD-Card
TFT-Anschluss ( 5" mit Rahmen bei mir ) ( Stiftleiste + I2C + SPI )
2 x CAN ohne Treiber ( Stiftleiste )
Anschluss für nRF24L01+ Funkmodul + extra Versorgung ( Buchsenleiste
10pol.)
Möglichkeit für das WLAN-Modul GSM2100 zum Auflöten ( extra Versorgung )
Versorgung extern 12V
Versorgung intern +5V/2A, 3,3V/1A ( MCU, SDRAM )
Soundcontroller BU8793KN plus Class-D 2W
3 x USART ( 1x zum Update ) ( 2 x Service )
Debug Jtag und Trace
Das Board dient mir für Test's für WLAN und Motorsteuerung (
Buchsenleiste )
Das kann natürlich auch anders genutzt werden.
Steffen H. schrieb:> Mein Board mit dem STM32F746BGT6 ist fertig und in Produktion> Rohleiterplatten )>> 64 MB SDRAM ( 2 x 32MB )> Ethernet MII> USB-OTG FS> SPI-Flash 8MB> SD-Card> TFT-Anschluss ( 5" mit Rahmen bei mir ) ( Stiftleiste + I2C + SPI )> 2 x CAN ohne Treiber ( Stiftleiste )> Anschluss für nRF24L01+ Funkmodul + extra Versorgung ( Buchsenleiste> 10pol.)> Möglichkeit für das WLAN-Modul GSM2100 zum Auflöten ( extra Versorgung )> Versorgung extern 12V> Versorgung intern +5V/2A, 3,3V/1A ( MCU, SDRAM )> Soundcontroller BU8793KN plus Class-D 2W> 3 x USART ( 1x zum Update ) ( 2 x Service )> Debug Jtag und Trace>> Das Board dient mir für Test's für WLAN und Motorsteuerung (> Buchsenleiste )> Das kann natürlich auch anders genutzt werden.
Sieht super aus. Könntest du, wenn die Leiterplatten fertig sind einige
Bilder machen? Evtl. einen neuen Thread unter Projekte.
Gruß
@ Felix L.
das kann ich machen. Das wird aber noch ein bischen dauern, da die
Leiterplatten in etwa 10 Tagen bei mir sind. Bauteile sind ja nun jetzt
alle bei mir eingetroffen.
Gruss
Steffen
Hallo zusammen,
zum Thema Display und User Interface:
Habe vor einiger Zeit mal mit dem STM32F4 DISCO experimentiert, aber das
LCD am STM32F4 Board mit resistivem Touch war ja nicht wirklich toll.
Bin jetzt gerade auf das neue STM32F7 Board gestossen. Dort scheint ja
ein qualitativ besseres LCD mit höherer Auflösung und vor allem
kapazitivem Touch montiert zu sein.
Die Grafik Performance scheint ja auch beeindruckend zu sein - gibt zwar
erst wenige Demos zu sehen, aber sowas suche ich:
https://youtu.be/RdPc5LVkyvI
Leider ist das eine kommerzielle Lösung, drum meine Frage an die die
schon ein Board haben: Was ist denn da zum Thema Graphics/GUI
mitgeliefert?
Gruß
Albert schrieb:> Was ist denn da zum Thema Graphics/GUI mitgeliefert?
Nunja
- du kannst dir aus den HAL/ BSP Treibern was eignes bauen
- du kannst die "mitgelieferte" STemWIN nutzen (kommerziell, aber hier
frei)
- du kannst das hier nutzen: http://ugfx.org/
"Mitgeliefert" heißt hier: Teil der Firmware:
http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1743/LN1897/PF261909
Mit µGFX habe ich keine Erfahrungen bisher. Sieht aber durchaus
interessant aus und ist frei.
Hallo,
wenn ich mich nicht verlesen habe ist Touch GFX:
http://touchgfx.com/product-details/evaluation/
Gemäß aussage uneingeschränt nutzbar zum testen und nicht kommerzielle
Lösungen = "persöhnlichen Gebrauch".
µGFX läuft seit ein paar Stunden auf diesem board. Bisher jedoch nur das
Display, am Touchscreen arbeiten wir gerade.
Lizenztechnisch ist µGFX auch komplett frei für jede art von
nicht-kommerziellem gebrauch. Der Quellcode ist zu 100% offen.
Tectu schrieb:> µGFX läuft seit ein paar Stunden auf diesem board. Bisher jedoch nur das> Display, am Touchscreen arbeiten wir gerade.> Lizenztechnisch ist µGFX auch komplett frei für jede art von> nicht-kommerziellem gebrauch. Der Quellcode ist zu 100% offen.
Hast Du evtl. noch ein paar Hinweise, wie Du µGFX zum Laufen gebracht
hast?
Welche Entwicklungsumgebung, Einstellungen, Tipps & Tricks ...?
Danke vorab schon mal!
Uwe N. schrieb:> Ich bezweifel ganz stark, dass das "Nö" von demselben Tectu wie weiter> oben stammt...
Und was bitte bewegt Dich zu diesem Zweifel?
Wir haben hier etliche Stunden verbracht um das ans Laufen zu bekommen.
Wenn noch nicht einmal die Frage nach der IDE geklärt ist, dann kann ich
mir kaum vorstellen dass er mit Hilfe von ein paar kurzen Stichpunkten
µGFX ans Laufen bekommt.
Tectu schrieb:> Uwe N. schrieb:>> Ich bezweifel ganz stark, dass das "Nö" von demselben Tectu wie weiter>> oben stammt...>> Und was bitte bewegt Dich zu diesem Zweifel?>> Wir haben hier etliche Stunden verbracht um das ans Laufen zu bekommen.> Wenn noch nicht einmal die Frage nach der IDE geklärt ist, dann kann ich> mir kaum vorstellen dass er mit Hilfe von ein paar kurzen Stichpunkten> µGFX ans Laufen bekommt.
Dann wäre es aber auch sehr sinnvoll, solche Beiträge komplett zu
unterlassen.
Warum?
Weil sich der Nutzwert für die Besucher des Forums gegen Null bewegt.
Hat schon jemand eine Möglichkeit entdecken können, einen externen
JTAG/SWD-Debugger anzuschließen? Bei den anderen Discovery-Boards klappt
das ja über Umwege. Der nicht bestückte Header ist leider das SWD für
den ST-Link. Eventuell über den Arduino-Header?
Tectu schrieb:> Und was bitte bewegt Dich zu diesem Zweifel?
Deine überraschend einsilbige Antwort - könnte ja auch ein Troll in
deinem Namen schreiben. Das ist für mich, da du als Gast hier unterwegs
bist, nicht erkennbar. Ich respektiere eure Arbeit - keine Frage. Aber
deine Antwort hätte durchaus höflicher sein können.
Uwe B. schrieb:> SB 14-17 entfernen und Leitungen anlöten erscheint mir die einzige> Moeglichkeit, ist aber nicht besonders praktikabel...
Könnte mir unpraktikableres vorstellen, als Lötbrücken zu kontaktieren
;) Werde das gleich mal testen. Danke für den Hinweis!
Mit den entfernten Lötbrücken lässt sich die MCU regulär per SWD
steuern. SB14 = SWCLK, SB15 = NRST, SB16 = SWO, SB17 = SWDIO. Über den
unbestückten Header kommt man an GND und 3.3V.
Leider reichen die 300mA vom J-Link nicht aus, deshalb kommt man um das
USB-Kabel nicht herum.
Uwe Bonnes schrieb:> Was ist der Grund fuer den externen Adapter? Was fehlt am ST-Link?
Die Linux-Unterstützung vom ST-Link ist eher schmerzhaft. Der GDB-Server
vom inoffiziellen stlink-Tool ist sehr instabil, OpenOCD ist noch
schlimmer.
Im Gegensatz dazu ist der J-Link mit dem gut gepflegten eigenen GDB ein
Traum. Arbeitet mit Eclipse und dem ARM-Plugin perfekt zusammen.
Uwe Bonnes schrieb:> Martin K. schrieb:>> Hmm,>>>> Ich warte noch auf den STM32F7 mit 2MB internem Flash, damit möchte ich>> den STM32F429 ersetzen, den ich nur mit 168MHz Takten kann, da sonst der>> FS USB nicht mehr läuft. Beim F7 sollen die internen Takte ja freier>> verwendbar sein…>> Warum so grossen interner Flash? Was spricht gegen QSPI?
Weil der so einen STM32F429II ersetzen könnte ohne das etwas am
aktuellen Board geändert werden müsste.
Gruß
Martin
René K. schrieb:> Uwe Bonnes schrieb:>> Was ist der Grund fuer den externen Adapter? Was fehlt am ST-Link?>> Die Linux-Unterstützung vom ST-Link ist eher schmerzhaft. Der GDB-Server> vom inoffiziellen stlink-Tool ist sehr instabil, OpenOCD ist noch> schlimmer.
Ich habe eine "Translation DLL" mit der man STLINK unter Wine laufen
lassen kann.
https://github.com/UweBonnes/wine/tree/stlink
Inzwischen gibt es mit stsw_link_3.6 ja auch eine Linux
libSTLinkUSBDriver.so auf die man umlenken könnte, ich bin aber noch
nicht zum implementieren gekommen.
Für OpenOCD gibt es auch Patches von Remi PRUD'HOMME', allerdings falle
ich mein Single Stepping an bestimmten Stellen in eine Endlosschleife...
Es gibt noch einen anderen Weg, den ST-Link vernünftig unter Linux zu
nutzen. Man braucht hierzu Eclipse und die OpenSTM32-Plugins. Dazu
installiert man von der Updatesite
http://www.ac6-tools.com/Eclipse-updates/org.openstm32.system-workbench.site
alle Linux-Pakete. Zusätzlich wird openocd (sinnvollerweise aus dem
Distributions-Paketmanagement) benötigt.
Unter "New Project" wird jetzt u.a. auch der STM32F7 inkl. dem
Discoveryboard angeboten (ARM Eclipse ist noch nicht so weit..). U.u.
muss man noch den Pfad zur Toolchain anpassen. Dann kann man schonmal
lauffähige Kompilate erzeugen.
Das Debugging über ST-Link klappt mit dem Ac6 STM32 Template. Hier
müssen noch Projekt und Binary ausgewählt und der Pfad zu
arm-none-eabi-gdb gesetzt werden. Danach funktioniert alles wunderbar.
Das Beispiel aus der STM32Cube_FW_F7_V1.1.0 Lib mal zurechtgepatcht
damit es mit der 32k Version von Keil auskommt. Das eingebettete Bild
sprengt sonst das 32k Limit. Die Timings für das TFT stehen in der
readme.txt
Gruß,
dasrotemopped.
PS Update von CubeMX auf 4.9.0 ist released
Thomas S. schrieb:> Hast Du evtl. noch ein paar Hinweise, wie Du µGFX zum Laufen gebracht> hast?> Welche Entwicklungsumgebung, Einstellungen, Tipps & Tricks ...?>> Danke vorab schon mal!
Hallo,
Entschuldige die späte Antwort. Ich war die letzten paar Tage im Urlaub.
Das 'nö' kommt nicht von mir sondern von irgend einem Witzbold.
Ich selbst verwende einfach nur einen Texteditor und Make als "IDE".
Gelegentlich verwende ich EmBlocks.
Wenn du dich bei mir per E-Mail oder im uGFX Forum meldest lasse ich dir
gerne mein Projekt als ZIP Datei zukommen.
Mit freundlichen Grüssen,
Tectu
Display, Ram und uGFX laufen bei mir jetzt, ich kämpfe aber noch mit dem
Touchcontroller. Mit HAL_I2C_IsDeviceReady bekomme ich zwar nach den im
Beispiel genannten 300ms Wartezeit eine positive Antwort, jegliche
Lesevorgänge der Chip ID schlagen jedoch fehl. Ist da jemand auch grad
dran?
Mein Projekt (Makefile basiert und optional mit Em::Blocks) ist jetzt
öffentlich verfügbar. Jedoch ist da zur Zeit noch nichts aufgeräumt. Ich
habe einfach schnell den ganzen Ordner auf BitBucket geladen.
Weitere Informationen hier:
http://forum.ugfx.org/viewtopic.php?f=22&t=254
@René: Ich arbeite zur Zeit am Touchscreen. Jedoch verzweifle ich am
I2C. Ich versuche das ganze mit direktem Registerzugriff zu erledigen
(d.h. ohne den STM32Cube HAL) damit alle Platformen (BareMetal,
FreeRTOS, ChibiOS, etc.) die uGFX board files benutzten können.
Ich teste das ganze zur Zeit mit dem Code in stm32f7_i2c.c. Leider
bekomme ich jedoch die I2C Bus Taktfrequenz (SCL Frequenz) nicht auf
unter 1.35 MHz. Die Timings habe ich vom Beispielcode von ST übernommen.
Die Clock source habe ich auch entsprechend ausgewählt...
Zur Zeit bin ich da ratlos. Bis der I2C auf 100 kHz läuft wird der
touchcontroller halt auch nicht wirklich Antwort geben ;)
(Die ST beispielcode Doku sagt dass das Board nichtmal 400 kHz kann).
Jegliche Art von Rat ist herzlichst willkommen (im uGFX Forum, nach
Möglichkeit).
Joel B. schrieb:> @René: Ich arbeite zur Zeit am Touchscreen. Jedoch verzweifle ich am> I2C. Ich versuche das ganze mit direktem Registerzugriff zu erledigen> (d.h. ohne den STM32Cube HAL) damit alle Platformen (BareMetal,> FreeRTOS, ChibiOS, etc.) die uGFX board files benutzten können.> Ich teste das ganze zur Zeit mit dem Code in stm32f7_i2c.c. Leider> bekomme ich jedoch die I2C Bus Taktfrequenz (SCL Frequenz) nicht auf> unter 1.35 MHz. Die Timings habe ich vom Beispielcode von ST übernommen.> Die Clock source habe ich auch entsprechend ausgewählt...> Zur Zeit bin ich da ratlos. Bis der I2C auf 100 kHz läuft wird der> touchcontroller halt auch nicht wirklich Antwort geben ;)> (Die ST beispielcode Doku sagt dass das Board nichtmal 400 kHz kann).> Jegliche Art von Rat ist herzlichst willkommen (im uGFX Forum, nach> Möglichkeit).
Genau daran scheitere ich auch gerade.
René K. schrieb:> Genau daran scheitere ich auch gerade.
Hast du irgend eine idee? Im Errata steht dazu auch nichts.
Ich hab dir mal ne mail geschrieben.
Ich habe nun die Timings vom STM23CubeMX generieren lassen und das
problem bleibt das selbe. Die SCL Frequenz ist immer entweder ~1MHz oder
~2MHz.
PLL settings scheinen zu stimmen. 200MHz ist SYSCLK und I2CCLK ist 50MHz
(APB1 Frequenz welche SYSCLK/4 ist).
Joel Bodenmann schrieb:
>Ich bin echt ratlos
Ich bin ja nun auch nicht der Experte aber in deinem init code steht:
RCC->DCKCFGR2 &= ~RCC_DCKCFGR2_I2C2SEL;
in der HAL steht aber:
/** @brief Macro to configure the I2C2 clock (I2C2CLK).
*
* @param __I2C2_CLKSOURCE__: specifies the I2C2 clock source.
* This parameter can be one of the following values:
* @arg RCC_I2C2CLKSOURCE_PCLK1: PCLK1 selected as I2C2
clock
* @arg RCC_I2C2CLKSOURCE_HSI: HSI selected as I2C2 clock
* @arg RCC_I2C2CLKSOURCE_SYSCLK: System Clock selected as
I2C2 clock
*/
#define __HAL_RCC_I2C2_CONFIG(_I2C2_CLKSOURCE_) \
MODIFY_REG(RCC->DCKCFGR2, RCC_DCKCFGR2_I2C2SEL,
(uint32_t)(_I2C2_CLKSOURCE_))
wobei modify reg 3 parameter hat
- das register
- die bitmaske um nur einzelne bits zu ändern
-der wert
Es könnte vieleicht sein das du die Bitmaske statt des Wertes in das
Register schiebst.
m.f.G.
Dieter
Danke für deinen Post Dieter. Es stellte sich heraus dass das Problem
noch viel peinlicher ist. Siehe ST-Forum.
Sowas sollte einfach nicht passieren nach vier Jahren arbeiten mit
STM32...
Heisses Teil ;-)
Ich habe mal das HAL BSP Example als luna Projekt angehängt.
Unter ubuntu nutze ich zum debug ein modifiziertes openocd:
openocd bauen:
Ich habe es tatsächlich fast geschafft das Demo das original auf dem
Board ist als eclipse/makefile Projekt zu erstellen.
Mit dem openocd von oben ist aber die Programmierung des QSPI nicht
möglich.
Mit ST-Utils v3.6 kann ich die .hex auch nicht übertragen.
Hat jemand eine Idee wie ich den QSPI füttern kann?
Vielleicht ist ja texane bald soweit? :)
Ich glaube (nicht probiert - nur gelesen) das funktioniert schon per
ST Link Utility v3.6 und dem externen Loader.
Genaueres hierzu steht (afaik) im "read me" des QSPI Performance Test im
Application Ordner der aktuellen F7 Firmeware.
Vielleicht nutzt das was...
Hat geklappt!
Gestern gab es von ST schon die Beschreibung von v3.7 aber im Download
war noch die v3.6.
Heute gibt es das ST-LINK Utility v3.7 und da wird das Board mit
external Loader voll unterstützt :-)
Joel B. schrieb:> So, TouchScreen Treiber ist jetzt in uGFX auch vorhanden.> Have fun!
Hallo,
kannst Du mal Starthilfe geben. Auf dem Rechen (Linux, Opensuse 13.2)
habe ich
- arm--none-eabi-xxx 4.9.3 20150529
- STM32Cube/Repository/STM32Cube_FW_F7_V1.0.0/
- den ausgecheckten ugfx Alternate_Raw32_Scheduler Branch
make -f ./boards/base/STM32F746-Discovery/example_raw32/Makefile
bricht ab mit:
In file included from
../ugfx/boards/base/STM32F746-Discovery/stm32f746g_discovery_sdram.c:80:
0:
../ugfx/boards/base/STM32F746-Discovery/stm32f746g_discovery_sdram.h:48:
31: fatal error: stm32f7xx_hal_rcc.h: No such file or directory
#include "stm32f7xx_hal_rcc.h"
Also in ./boards/base/STM32F746-Discovery/example_raw32/Makefile die
Eintrage für CMSIS und HAL auf die lokalen Verzeichnisse umgelenkt.
Jetzt kommt neben Warnungen als Fehler
In file included from
../ugfx/boards/base/STM32F746-Discovery/stm32f7xx_ll_fmc.c:77:0:
/home/bon/.wine/drive_c/users/bon/STM32Cube/Repository/STM32Cube_FW_F7_V
1.1.0/Drivers/STM32F7xx_HAL_Driver//Inc/stm32f7xx_hal.h:48:32: fatal
error: stm32f7xx_hal_conf.h: No such file or directory
#include "stm32f7xx_hal_conf.h"
Das File ist zwar vorhanden, aber die Include Pfade stimmen nicht.
Ich habe mir das Projekt von tectu auch mal angesehen.
Wenn man STM32CubeMX nutzt legt dieses im Homeverzeichnis seine HAL-Libs
ab.
Unter der Vorraussetzung habe ich einen Ablaufplan erstellt um das
Projekt zu bauen:
Arbeitsverzeichnis anlegen:
Wer ein DISCO Board hat, der sei auf einen Fehler in der Doku
hingewiesen:
Am Arduino Header liegt das NSS Signal für die SPI2 nicht am
Steckeranschluss D10, sondern am D5 (Port I, Bit 0)
Der Schaltplan und Doku Fehler hat mich jetzt tagelang bei der
Inbetriebnahme der SPI im Slave Modus genarrt.
Da in der zip fast ausschliesslich frei erhältliches Zeug ist wie:
dotNet, jre, cubemx, STUtility, hallib und nur ein winziges Projekt, ist
es kein Problem für mich einen zip cracker zu empfehlen.
Der hat nicht viel zu tun, sind nur 5 Zeichen.
Hallo zusammen
@René K du hast ja deinen J-Link ans F7 Discovery angeschlossen, hast du
die SB14-17 entfernt oder ersetzt oder einfach auf der F7 seite die
Kabel angelötet? Hintergrund meiner frage ist, dass ich gerne beide
möglichkeitten hätte, um notfalls den angebauten ST-Link benutzen zu
können. Mein Vorschlag wäre gewesen, die 0R Widerstände durch 10k oder
so zu ersetzen, und dann auf der F7 seite den Stecker für den J-Link
anzuschliessen. Macht dieses Vorgehen Sinn?
Mfg
Ich habe die Brücken entfernt, da ich den ST-Link nicht mehr nutzen
werden. 10k könnte funktionieren (auf den anderen Discovery-Boards
klappt es auch), eindeutig beantworten könnte man das aber nur, wenn man
sich SWD mal genau ansieht.
hi
ich tu mich noch schwer damit ein tamplate zum laufen zu bekommen.
also IDE hab ich bisher Coocox verwendet.
aufgrund einiger ungereimtheiten bewege ich momentan
alle projekte richtung eclipse + GCC
hat da jemand ein einfaches projekt zur hand?
eine leere main würde mir genügen ^^
PS:
ich bin mit "Projekt-> neu" groß geworden
und tu mich schwer mit makefiles und so selbst erstellen
die libs einbinden und so ist kein großes problem.
Siehe mein altes Posting:
Beitrag "Re: STM32F7 Discovery Board"
Einfach das Plugin installieren, dieses wird regelmäßig gepflegt und der
Projekt-Wizard funktioniert.
René K. schrieb:> Siehe mein altes Posting:>> Beitrag "Re: STM32F7 Discovery Board">> Einfach das Plugin installieren, dieses wird regelmäßig gepflegt und der> Projekt-Wizard funktioniert.
hi
danke hab ich wohl überlesen
sorry
werde das mal testen :-)
Hallo,
hat jemand schon das Debuggen am STM7 Discovery mit semihosting
hinbekommen? Ich nutze GDB mit OCD und da hängt es in der Routine
_swiwrite();
meine GCC optionen sind: -DUSE_DBG_PRINTF
-DUSE_SEMIHOSTING
Linkeroptionen: --specs=rdimon.specs -lc -lrdimon
und im Programm:
#ifdef USE_DBG_PRINTF
initialise_monitor_handles();
setbuf(stdout, NULL);
#endif
Vielleicht muß dem OCD noch was gesagt werden.Ich weiß bloß nicht was.
m.f.G.
Dieter
Bzgl. Linux auf STM32F7:
Wie fängt man da an? Muss man sich bei EmcraftSystems registrieren,
damit man (pre-compiled) U-Boot/Linux-Image laden kann?
Dort gibt es auch ein BSP gegen kleines Geld.
Ist es richtig, dass man dieses für einen ersten Versuch nicht
braucht?
Dort auf deren Webseite ist vieles als 2010.x
(wie U-Boot oder auch Compiler) angegeben:
http://www.emcraft.com/stm32f7-discovery-board/release-notes
Nicht schlagen. Aber wir haben jetzt das Jahr 2015.
Ist dies uraltes, und von denen gepatchtes Zeug?
Oder warum kann man da keine aktuellen Versionen nehmen?
Wenn ich U-Boot und Image downgeloadet habe, wie geht es dann weiter?
U-Boot flashen? Dann via TFTP das Linux-Image holen und starten?
Setzt dann einen TFTP-Server unter Windows oder Linux voraus?
Geht es auch ohne? Ist es nur einmalig nötig und dann
kann das Board stand-alone betrieben werden?
Gibt es da ein Tutorial, dass ganz speziell für den STM32F7 zurecht-
gemacht ist oder so allgemein, dass für den STM32F7 nichts
besonderes nötig ist?
Laut obigem Video bootet es recht schnell. Wie ist sonst so das
Arbeiten auf dem Board? Rennt der Compiler annehmbar schnell
oder ist man auf Cross-Compiling angewiesen?
Lukas L. schrieb:> Bzgl. Linux auf STM32F7:> Wie fängt man da an? Muss man sich bei EmcraftSystems registrieren,> damit man (pre-compiled) U-Boot/Linux-Image laden kann?
Ja
> Dort gibt es auch ein BSP gegen kleines Geld.> Ist es richtig, dass man dieses für einen ersten Versuch nicht> braucht?
Jein, je nachdem wie gut du bist und du die anderen downloadbaren
Packages
z.B. STM32F7-SOM verstehst und verwenden kannst
> Dort auf deren Webseite ist vieles als 2010.x> (wie U-Boot oder auch Compiler) angegeben:>> http://www.emcraft.com/stm32f7-discovery-board/release-notes>> Nicht schlagen. Aber wir haben jetzt das Jahr 2015.> Ist dies uraltes, und von denen gepatchtes Zeug?
Compiler alt, Kernel alt, Board Support Package aktuell
> Oder warum kann man da keine aktuellen Versionen nehmen?
es gibt keine aktive community mehr die uclinux pflegt, verschiedene
Hersteller z.B. Analog Devices für Blackfin haben die alten Quellen
geforkt
und pflegen ihre CPU's und Boards dort selber, ählich macht es emcraft
>> Wenn ich U-Boot und Image downgeloadet habe, wie geht es dann weiter?> U-Boot flashen? Dann via TFTP das Linux-Image holen und starten?
Ja, geht aber auch über Uart
> Setzt dann einen TFTP-Server unter Windows oder Linux voraus?
Netzwerk ja, Seriell nein
> Geht es auch ohne? Ist es nur einmalig nötig und dann> kann das Board stand-alone betrieben werden?
wenn Image + U-Boot size < 1MB, dann vom internen Flash stand-alone
möglich, SD-Card + QSPI theoretisch auch möglich, derzeit nicht
unterstützt
> Gibt es da ein Tutorial, dass ganz speziell für den STM32F7 zurecht-> gemacht ist oder so allgemein, dass für den STM32F7 nichts> besonderes nötig ist?
viele Tutorials, Handbuch ist für alle emcraft Platformen nahezu gleich
>> Laut obigem Video bootet es recht schnell. Wie ist sonst so das> Arbeiten auf dem Board? Rennt der Compiler annehmbar schnell> oder ist man auf Cross-Compiling angewiesen?
nur cross compiling
Hallo,
leider hat das mit meinem Testboard etwas länger gedauert, aber nun ist
es fertig. Ich habe noch nicht alles getestet, nur Versorgung, CPU,
SDRAM. Mir fehlt ein bischen die Zeit. Werde aber hier noch darüber
berichten. Wer interesse hat kann sich gern bei mir melden.
Leiterplatten habe ich erstmal drei bestückt, aber werde noch mehr
bestücken. Das wird aber erst im Dezember. Bauteile sind ja noch
genügend da.
Anbei noch Bilde dazu.
Bis bald,
Steffen
Hallo,
so, das Display und der SDRAM funktionieren nun auch. An dem
Touch-Treiber arbeite ich noch, da es zu dem Teil nicht wirklich viel
gibt. Anbei Bilder von dem Board mit Display.
Gruss,
Steffen
das Display mit Touch funktioniert nun auch. Das Display ist ein
ER-TFT-050 mit dem Touch-Controller GSL1680. Bei dem Touch-Controller
muss vorher eine Firmware geladen werden und noch auf Gültigkeit geprüft
werden. Die Firmware muss auch zum Display ( bei mir 800x480 ) passen.
War nicht einfach, aber funktioniert jetzt. Wo noch ein Problem besteht,
ist die Funktion "Multiple Buffering" bei der es bei mir zum flackern
kommt, wenn ich die Buffer auf mehr als einen setze. Der Line-Int beim
STM32F746 ist bei mir auf null gesetzt. Ich muss wahrscheinlich den
Register Reload INT ( RRIF ) nehmen, der bei der Vertikalaustastperiode
kommt. Keine Ahnung, warum ST das so im Bsp. mit Lini-Int gemacht hat.
Ich werde das noch testen und darüber berichten.
Als letztes kommt jetzt noch Ethernet und WLAN.
Gruss
Steffen
Hat jemand schon die Ethernet Schnittstelle am laufen? Mich würde ein
Beispiel Projekt interessieren. Einfacher Webserver oder udp... Bisher
konnte ich nicht viel entdecken....
So. Bei mir tut's EEENDLICH auch.
Ubuntu + STM32F7 Disco + openstm32 + texane/stlink
Das hier gepostete STM32F746NGH_Disco.ioc passt aber nicht zum Board. In
der Datei ist ein HSE Oszillator von 8MHz angegeben. Das Board hat 25MHz
drauf. Nach dem Startup blieb es immer hängen.
Hi,
ich krame das Thema mal wieder hervor. Auch ich versuche mich momentan
am STM32F7-Disco.
Ich arbeite mit CubeMx sowie System Workbench von ST. Soweit habe ich
auch alles zum laufen gebracht, UART, Timer, Interrupt... LED blinkt
usw. Etwas gewöhnungsbedürftig, der HAL und die Interruptverarbeitung
durch die callback funktionen. Nungut...
Soweit bin ich nun durchgestiegen und die erste LED blinkt. Jetzt würde
ich gerne mal das Display ansteuern. Jedoch bleibt mein Bildschrim
schwarz. Mit dem Beispielprogramm funktioniert es. Ich versuche es
jedoch mit CubeMx zu initialisieren.
Die Initialisierung sieht im Endeffekt genau so aus, wie die im
Beispiel, funktioniert jedoch nicht.
Für die Taktfrequenz am LCD habe ich 9,6MHz gewählt (565
(totalheight)*285 (totalwidth) * 60Hz = 9,6... MHz)
Ich kann beim besten Willen kein Unterschied feststellen. Hat jemand von
euch das ganze schon mit CubeMx zum laufen bekommen? mein Code ist ein
wenig anders strukturiert als das Beispiel (durch Cube eben), aber
dennoch sollte alles vorhanden sein.
Steffen H. schrieb:> leider hat das mit meinem Testboard etwas länger gedauert, aber nun ist> es fertig
Hallo Steffen,
hast Du noch Leerplatinen übrig?
VG Pete
@wods
Hier ist mein Projekt mit dem STM32F7 disco.
Hab es mit CubeMx exportiert, bevor ich es aber in Github eingecheckt
habe, habe ich die Verzeichnissstruktur nochmals geändert, anstatt den
Links auf Dateien stehen die Dateien jetzt direkt in den Ordnern.
Deshalb geht jetzt ein direkter Export aus CubeMX zwar nicht mehr, aber
man kann ja schauen, was exportiert worden ist und Du kannst es mit
Deinen Files vergleichen.
Wie oben beschrieben musste ich auf 25MHz umstellen.
https://github.com/gerdb/weldingmeter
@Pete K.
ja, sind noch einige da. Schicke mir doch mal ne PN, dann kann ich Dir
schonmal die BOM und Bestückung schicken. Die Rohleiterplatten liegen
bei 44,00 EUR/ Stück. Sind nicht billig, da ich nur 20 Stück bestellt
habe und die 6 Lagen haben mit einen besonderen Lagenaufbau. Die
Bauteilkosten liegen bei etwa 56,00 EUR, kommt aber immer darauf an, was
man alles bestücken will. Der STM32F746BGT6 kostet ja schon 12,15 EUR.
Die Schaltung schonmal vorab.
Gruss
Steffen
@Pete:
da ich die Leiterplatte doch nochmal anfassen muss, um auch die neuen
STM32F7xx mit @400MHz betreiben zu können, werde ich dann eine größere
Anzahl bestellen. Der Preis für eine Rohleiterplatte liegt dann zwischen
12,00 EUR und 15,00 EUR. Der Preis ist dann doch schon etwas besser für
eine 6L Leiterplatte.
Wer die Daten von dem Rahmen des 5" Display haben möchte ( STEP/STL ),
der kann mich gern anschreiben. Das Display ist ein ER-TFT-050 mit cap.
Touch.
http://www.buydisplay.com/default/5-tft-lcd-display-module-wvga-800x480-high-resolution-for-mp4-gps
Gruss,
Steffen
wods schrieb:> Ich kann beim besten Willen kein Unterschied feststellen. Hat jemand von> euch das ganze schon mit CubeMx zum laufen bekommen? mein Code ist ein> wenig anders strukturiert als das Beispiel (durch Cube eben), aber> dennoch sollte alles vorhanden sein.
Okay, nach 2 Tagen Codevergleichen und Probleme suchen, habe ich es mein
Problem gefunden.
Versteckt in der 3. Unterfunktion im 100sten HAL_INIT_wasweißich,
folgender Code:
Steffen H. schrieb:> Der Preis für eine Rohleiterplatte liegt dann zwischen> 12,00 EUR und 15,00 EUR. Der Preis ist dann doch schon etwas besser für> eine 6L Leiterplatte.
Mach Dir mal nicht zu klein ;-)
Immerhin ist Dein Arbeitsaufwand fürs Layout doch nicht zu
unterschätzen.
Aktuell gibt es Nucleo Boards mit dem ..746. Falls man nur den nackten
Prozesser in Minimalbeschaltung braucht, wäre das auch eine Alternative
zum Disco-Board.
Steffen H. schrieb:> um auch die neuen> STM32F7xx mit @400MHz betreiben zu können,
Dauert doch sicher noch Ewigkeiten bis die kommen, oder gibts da schon
Neuigkeiten?
Da stand schon vor langer Zeit mal was von einer Roadmap für höhere
Taktraten, aber nix konkretes.
Noch backt ST ja immer noch mit ihrem 90nm Flash Prozess...
Btw. hat eigentlich mal wer den realen Energiebedarf vom STM32F7 @216MHz
@3.3V gemessen?
>Dauert doch sicher noch Ewigkeiten bis die kommen, oder gibts da schon>Neuigkeiten?
nächste Woche ist ST bei uns in der Firma, da bekomme ich die
entsprechenden Informationen, da das ein Thema in dieser Besprechung
ist. Da kann ich dann mehr sagen, wann die auf dem Markt kommen, bzw.
die ersten Engineering Samples zur Verfügung stehen und die
entsprechenden Daten.
Zuse schrieb:> Steffen H. schrieb:>> um auch die neuen>> STM32F7xx mit @400MHz betreiben zu können,>>> Dauert doch sicher noch Ewigkeiten bis die kommen, oder gibts da schon> Neuigkeiten?> Da stand schon vor langer Zeit mal was von einer Roadmap für höhere> Taktraten, aber nix konkretes.> Noch backt ST ja immer noch mit ihrem 90nm Flash Prozess...
400 MHz bräuchte ich zwar nicht, aber High Speed USB ohne externen ULPI
wäre nett und ein Pinout, das nicht so bescheiden ist wie jetzt.
Letzteres gilt aber ebenso für PIC32MZ oder SAM V und S. Da könnten sich
die Hersteller mal u.a. bei Renesas, Rockchip oder Allwinner ein Vorbild
nehmen...
Und bei allen genannten: SDRAMs (bei Microchip wäre ich schon froh, wenn
sie SDRAM könnten...) sterben aus insb. wenn die Teile auch noch etwas
stromsparend sein sollen und nicht im Standby mehr als der ganze Rest
der Schaltung verbraten sollen.
Zurück zum Thema: Vielleicht sollte ich das F7-Disco mal entstauben und
das irgendwann angedachte Multieffektgerät anfangen... Alles nötige hat
das Board ja
Arc N. schrieb:> aber High Speed USB ohne externen ULPI> wäre nett und ein Pinout, das nicht so bescheiden ist wie jetzt.> ...> SDRAMs
Dito!
Dazu müsste man allerdings mal eine extra I/O Bank mit separat wählbarer
Spannung für den (LPDDRx) Speicher einführen die laufen halt nicht mit
3.3V...
Allerdings, der Vergleich zu Rockchip+Allwinner hinkt etwas, die machen
keine Mikrocontroller soweit ich weiss und das meiste hat sehr
hochpolige Gehäuse.
Bei Apps Prozessoren in 40/28nm hat man schon etwas mehr Transistoren
und Pins zur Verfügung um da bessere Pinmux Optionen vorzusehen.
Und die müssen nicht auf Pinkompatibilität mit Vorgängern seit 2007
achten.
Den F7 gibts in 7 stark unterschiedlichen Packages von 100 Pin LQFP -
216 Pin BGA, alle mit demselben Die... da muss man wohl Kompromisse
eingehen.
Was auch auffällt ist, dass die sehr hochpoligen STM32F4/7 Packages auf
vielen der zusätzlichen Pins fast nur den Display Controller liegen
haben. Keine der eigentlich interessanten Schnittstellen hat da
zusätzliche Pinmux Optionen. Die versuchen da wohl möglichst alle
Schnittstellen auf die bei JEDEM Package vorhandenen Pins zu quetschen -
und/oder den Display Controller frei zu halten...
Hi,
ich hab ne Frage zur Dokumentation vom Disco. Evtl. bin ich einfach nur
zu blöd und mir fehlt das richtige Dokument. Aber im UM zum Disco finde
ich keine Vernünftigen Angaben zur Belegung der Peripherie.
Bsp. dass auf welche UART ich über die USB Schnittstelle komme (habe ich
nur durch google in diversen foren gefunden, dass es USART1 ist)
ebenso welche I2C Schnittstelle auf den Touchcontroller geht (I2C3 für
ebenfalls suchende) und auf welchen Pin der Interrupt vom
Touchcontroller geht.
Gibt es hierfür irgendwelche vernünftigen Dokumente? Bei den SAMs von
Atmel steht das zum beispiel super erklärt im UsersGuide oder so.
gruß
wods schrieb:> Bsp. dass auf welche UART ich über die USB Schnittstelle komme (habe ich> nur durch google in diversen foren gefunden, dass es USART1 ist)>> ebenso welche I2C Schnittstelle auf den Touchcontroller geht (I2C3 für> ebenfalls suchende) und auf welchen Pin der Interrupt vom> Touchcontroller geht.
Schau in den Schaltplan und dann ins Datenblatt des Chips, welcher Pin
wo hin geht.
Hi,
auch ich habe mich vor einiger Zeit an das STM32F7 Disco gewagt.
Nun läuft bei mir soweit alles prima, aber ich kenne mich nicht so
richtig mit der Bildkonvertierung aus. Kann mir hier evtl. jemand mit
einem Link oder kurzen Infos auf die Sprünge helfen?
Wie speicher ich am besten möglichst viele Bilder/grafiken in möglichst
guter/ausreichender Qualität auf meinem nur 1MB großen Flash?
Sehe ich das richtig, dass ich das am besten mit einem CLUT hinbekomme?
Falls ja, wie konvertiere ich die Grafiken am einfachsten (und aus
welchem Format) in ein Array und wie generier ich den CLUT.
Davon abgesehen, habe ich auch noch kein vernünftiges Programm gefunden,
welches mir .bmp in verschiedenen Ausgangsformaten Formaten (ARGB888,
ARGB1555, RGB565, ARGB444, ...) direkt in ein Array konvertieren kann
(unabhängig von der Bildgröße).
läuft es darauf hinaus, dass ich mir ein eigenes kleines prog. schreiben
muss?
>gestern war ja ST bei uns, ..
Bist Du immer so freizügig beim Erzählen? Steht in Deinem Arbeitsvertrag
keine Geheimhaltungsklausel?
Würde ich zum Kunden fahren und mit ihm neue Visionen und Pläne
besprechen wollte ich nicht, dass der nächstbeste Mitarbeiten die gleich
im Netz veröffentlicht.
Steffen H. schrieb im Beitrag #4500300:
> 400MHz Dualcore
Oh sehr nett!
> Q1/2017
Ah, immerhin früher als ich dachte aber immer noch 1 Jahr langes Warten
;-)
> Das Cube-Mx wird auch überarbeitet,
..
> Low-Level-Treiber>
Oh sehr gut. Die CubeMX GUI ist toll und HAL ist eigentlich ganz nett
aber die Implementierung dahinter ist schon ziemlich aufgebläht...
Danke für die Infos!
chen schrieb:> Wie speicher ich am besten möglichst viele Bilder/grafiken in möglichst> guter/ausreichender Qualität auf meinem nur 1MB großen Flash?
Vor dem Problem stehe ich auch. Ich möchte ein größeres Display
anschließen. Nun ist mein SRAM zu klein (800x480 x16Bit = 768kByte) als
Buffer für einen Frame. Nun möchte ich den Externen SDRAM mit dem FMC
verwenden, doch komme nicht weiter.
Wie muss ich bei der Initialisierung vorgehen? Ich muss schätzungsweise
auch was am Linkerscript ändern oder?
Und wie initialisier ich die Sache so, dass ich den ext SDRAM wie meinen
ganz normalen SRAM ohne spezielle Adressierung verwenden kann? habe
leider keine AppNotes o.ä. von STM gefunden. UNd einfach nur CUBE und
FMC in betrieb nehmen ist nicht. Auch mit dem example komme ich
irgendwie nicht richtig weiter.
tipps?
chen schrieb:> Wie speicher ich am besten möglichst viele Bilder/grafiken in möglichst> guter/ausreichender Qualität auf meinem nur 1MB großen Flash?
Den internen Flash würde ich dafür nicht verschwenden wollen. Auf dem
Board ist ja immerhin noch ein 16Mb QSPI Flash verbaut.
chen schrieb:> Davon abgesehen, habe ich auch noch kein vernünftiges Programm gefunden,> welches mir .bmp in verschiedenen Ausgangsformaten Formaten (ARGB888,> ARGB1555, RGB565, ARGB444, ...) direkt in ein Array konvertieren kann> (unabhängig von der Bildgröße).
Lade dir von hier:
http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1743/LN1897/PF261909
die aktuelle Firmware herunter. Da ist im Ordner Middlewares/ St/
STemWin enthalten. Und im Ordner Software findest du einen netten
Converter für Bilder: BmpCvt.
SDRAM schrieb:> Wie muss ich bei der Initialisierung vorgehen? Ich muss schätzungsweise> auch was am Linkerscript ändern oder?
Nur wenn du MALLOC verwenden willst. Ansonsten reicht die Adressierung
jenseits von 0x0c00000 um auf den SDRAM zugreifen zu können.
Steffen H. schrieb:> im STM32CubeF7 sind Beispiele zum SDRAM.>> http://www.st.com/web/en/catalog/tools/PF261909>> \STM32Cube_FW_F7_V1.2.0\Drivers\BSP\STM32746G-Discovery\stm32746g_discov> ery_sdram.c
Die kannte ich, danke. Aber ich habe die ganze zeit beim falschen
Example geschaut
(STM32Cube_FW_F7_V1.3.0\Projects\STM32746G-Discovery\Examples\FMC\FMC_SD
RAM)
aber was ich eigentlich gesucht hab, war:
STM32Cube_FW_F7_V1.3.0\Projects\STM32746G-Discovery\Examples\FMC\FMC_SDR
AM_DataMemory
Soweit sogut, habe jetzt im internen SRAM nurnoch den SP und der rest
ist alles auf dem externen (vorerst).
Nun habe ich aber das Problem, dass meine Peripherien nichtmehr so
richtig wollen. Ich kann über UART bsp. nichts mehr senden (hat vorher
einwandfrei geklappt). Die HAL_UART_Transmit() macht was sie soll, nur
beim beschreiben vom TD-Register passiert nichts, dieses bleibt leer
(habe die Speicherstelle angesehen und es wird einfach nichts
reingeschrieben). Hatte schonmal jemand ein ähnliches Problem oder ein
paar schlagworte für google? Auch andere Peripherien funktionieren nicht
richtig. I2C zum beispiel gibt mir den Status Locked zurück... LCD zeigt
auch nichts mehr an.
Oke, Tage später die Lösung:
Peripherie hat nicht initialisiert, weil HAL den clk nicht eingeschaltet
hat. Wieso genau weiß ich nicht. Beim Initialisieren mit HAL waren viele
Peripheriemodule nicht im State == HAL_XXX_STATE_RESET, sondern
irgendwie READY. Was bei der Initialisierung zur folge hat, dass
HAL_XXX_MSPInit() nicht aufgerufen wird, wodurch der clk nicht aktiviert
wird und somit alles nachfolgende nicht funktioniert. Wieso genau es
sich im state READY befindet war mir vorerst egal, ich habe einfach vor
der initialisierung den State manuell auf RESET gesetzt. Hilft erstmal.
Dann gings weiter mit externem SDRAM. Hab mich durch die Startup und
System files gearbeitet und mich in linkerscripts eingelesen. Auch das
habe ich jetzt erfolgreich hinbekommen. Hier hätte ich aber eine Frage:
momentan habe ich einfach ALLES auf den externen SDRam gepackt. Auf dem
internen SRam befindet sich momentan nurnoch der SP.
Ich habe also im linker script keine neuen bereiche eingefügt.
Mein ziel wäre es, nur den Framebuffer auf das externe SDRam zu legen
und alles andere im interenen zu lassen.
Nun habe ich jedoch nicht viel Ahnung vom Linkerscript.
Wie stelle ich das am besten an? 1. Ich erstelle mir ein neuen Mem
bereich:
1
MEMORY
2
{
3
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 1024K
4
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 320K
5
SDRAM (xrw) : ORIGIN = 0xC0000000, LENGTH = 8M
6
}
nun belasse ich das ganze linkerscript wie es ist, würde allerdings
gerne eine weitere section hinzufügen. in diese Section würde ich gerne
2 Arrays legen (2 Framebuffer), und falls möglich, alle daten, die
nichtmehr in den interen RAM bereich passen. Wie gehe ich hierbei vor?
Wie kann ich 2 RAM bereiche managen?
Bei der Konfiguration des Framebuffers wird direkt die Adresse gesetzt.
Eine Erweiterung des Linkerscripts ist dafür nicht notwendig.
Nur falls man C Variablen in den extra. Speicher legen möchte, ist eine
neue Section im Linkerscript notwendig.
Zumindest verwende ich es im F429 so. Und ich denke im F7 ist es
identisch.
VG
Olaf
Obgleich der Kommentar schon einige Monate alt ist, sein not eine
Anmerkung erlaubt, was den Betrieb eiens TFT-Displays am StM32F4
Discovery betrifft.
Es ist definitiv möglich ein 800x480Pixel Display mit 16Bit Farben in
Verbindung mit einem STM32F407VG bei 168Mhz flüssig laufen zu lassen.
Ich benutze ein 5"-TFT der ein SSD1963 einsetzt um das Display zu
treiben. Das funktioniniert tadelos und es bereitet auch ohne DMA keine
Problem das Display und das Touchfeld (resistiv) je als Thread eines
RTOS laufen zu lassen ohne dass es zuckt. Der STM32F407 auf dem Disco
mach noch viel mehr als nur das Display zu bedienen - dank RTOS lässt
sich sowas auch recht gut machen.
Ich möchte auch mal daran erinnern dass der STM32F4 ein Microcontroller
ist und kein Microprozessor a la ARNM-A9, ARM-A10 so sowas ist. Sein
Einsatzgebiet ist ein ganz anderer und der ist eben selten das Treiben
eines TFT-Displays. Dass dies durchaus schnell funtionieren kann zeigen
der STM32F429 und ST32F746 mit ihren On-Chip Controllern in Kombination
mitdem SDRAM. Man erkauft sich diese Performance mit viel Aufwand für
Verdrahtung des SDRAM und damit einhergehenden Verlusst vieler I/O Pins
und der nicht mehr verfügbaren On-Chip-Peripherie.
Ich habe den STM32F7 nur als Discovery-Board mit TFT und SDRAM on-Board
heir liegen. Sowas wie ein CAN-Bus Master, den der Chip bereitstellt,
ist leider durch das viele Verdrahte des externen RAM'S, FLASH und
Audio-Kram nicht mehr nutzbar. Der Arduino-Sockel ist IMHO ein
schlechter WITZ. Was die mehr als doppelt so hohe Rechenleistung des
CPU-Kerns in Verbindung mit einem externen TFT-Displays an Speed bringt
kann ich leider och nicht sagen. Der interne TFT-Controller rennt wie
Sau, was auch am nutzbaren DMA und dem extern SDRAM liegt. Der
Video-Speicher liegt im Adressraum der CPU - da muss man nicht über
Register rumhantieren um was im VideoRam zu ändern.
Wenn das "STM32F746 Nucleo144" für mich verfügbar ist, werde ich diese
Versuche mal machen. Ein schönes Board - dass alle Möglichkeiten offen
lässt und dabei noch ein Ethernet mit Trx liefert.
Noch was am Rand bemerkt - die Verlusste durch Einsatz eines externen
TFT-Controllers hängen stark vom Controllertypus ab. Es gibt eine
Implementation eines TFT-Display-Controllers der mit externem SDRAM
arbeitet und nur aus einer CPLD besteht. Das Ding soll auch sehr schnell
sein - deutlich schneller als die SSD19xx oder HX0815 Chips die typisch
in solchen Displays verbaut werden.
Ich benutze eine kommerzioelle Grafik-Lib und müsste dazu noch ein
Display-Treiber schreiben. Mal sehen - wenn ich mal Zeit und Lust dazu
habe.
Hat einer von euch schonmal direkt mit dem Discovery-Board und den
beiliegenden Bibliothekten von ST für das Discovery-Board das Grafik
Display zum Anzeigen von was auch immer gebracht?
Gemeint sind die beiden Dateien:
#ifndef __STM32746G_DISCOVERY_LCD_H
#include "../Components/rk043fn48h/rk043fn48h.h"
Welche Schritte sind zu durchlaufen, um das Display zum arbeiten zu
bewegen?
Die LED blinkt, aber das Display bleibt schwarz...
hab ich irgendeine Initialisierung nicht gemacht, irgendwas vergessen,
inaktiven Layer standardmäßig voreingestellt... hab echt keine Ahnung
warum das schwarz bleibt...
STM-Tester schrieb:> hab echt keine Ahnung warum das schwarz bleibt...
Vielleicht weil
BSP_LCD_SetBackColor();
nur die Farbe setzt aber noch nichts zeichnet?
Irgendein FillScreen oder DrawRectangle machen ?
Hi
Ich habe FreeRTOS und nutze heap_4
Den heap habe ich in den DTCM ( 64k ab 0x20000000) gelegt.
Da hier auch Stackvariablen der Tasks liegen ist der kleine Bonus an
Speed vieleicht nicht verkehrt.
Wenn man den heap größer 64k macht funktioniert es nicht richtig.
Die nächsten 240kb + 16kb sind SRAM.
Wobei ich hier auch nicht sicher bin ob es sinnvoll ist das so linear zu
lassen.
nun die Frage:
Kann man die 16kb ITCM auch für variablen nutzen ?
im Datenblatt steht das NUR die CPU zugreifen kann ...
keine Pheripherie.( auch kein DMA )
aber wenn dort ein 16k buffer für CPU eigene sachen liegt ..
wäre das möglich ?
Hallo - nach dem wir nun erörtert haben wie teuer ATMEL's Cortex sind
und dbai feststellten, dass die im 1000er Pack nur €6.80 pro Stück
kosten, überlege ich gerade welches meiner Projekte je diese große Zahl
an MCU's bedurfte - mmm, keins. Un nun kann die Debatte wieder um
Mindermengenpreise entfacht werden. Ich bleib bei den ST's und die
bekomme ich auch ohne großen TammTamm gleich um die Ecke.
Leider gilt dies nicht für das neue STm32F7Nucleo-144, was eigentlich
genau das richtige zum Basteln ist, weil kein Nutzloses Zeug wie MEMS,
USB, DAC, Tasten und LED's drauf sind. Eigentlich ideal wenn man viele
pins braucht. Dies ist im freien Handel jedoch noch nicht wirklich
verfügbar. Digikey und andere sind nicht frei oder deren Einzelpreis ist
zusammen mit den Versandkosten einfach zu hoch. Da ist wohl warten
angesagt. Die Chinesen wie WaveShare haben sich dem F7 auch angenommen,
leider jedoch nur mit 2mm Pin-Header - also nichts für eine
Lochrasterplatine - schade eigendlich.
Das F7Disco hab ich hier in der Ecke liegen, kann jedoch eigentlich
nichts damit machen, da weder CAN noch andere Signale verfügbar sind,
denn die werden ja für das Display verschwendet. Es sieht nett aus, das
war es aber schon. Das Multitouch gefällt mir gut - bei 4.3" lässt sich
jedoch nur begrenzt etwas sinvolles damit anstellen. Ein Taschenrechner
wäre möglich, habe aber schon einige in der Schublade.
Die Rechenleistung ist jedoch beeindruckend für so ein kleines System.
Für ein Microcontroller nicht schlecht.
Juppeck schrieb:> Leider gilt dies nicht für das neue STm32F7Nucleo-144, was eigentlich> genau das richtige zum Basteln ist, weil kein Nutzloses Zeug wie MEMS,> USB, DAC, Tasten und LED's drauf sind. Eigentlich ideal wenn man viele> pins braucht. Dies ist im freien Handel jedoch noch nicht wirklich> verfügbar. Digikey und andere sind nicht frei oder deren Einzelpreis ist> zusammen mit den Versandkosten einfach zu hoch. Da ist wohl warten> angesagt. Die Chinesen wie WaveShare haben sich dem F7 auch angenommen,> leider jedoch nur mit 2mm Pin-Header - also nichts für eine> Lochrasterplatine - schade eigendlich.
Also ganz richtig ist das nicht. Ich habe mein NUCLEO-F746ZG bereits
Anfang März für €28,30 brutto von HBE erhalten. Ist ein feines Teil,
eben wegen der vielen freien Anschlüsse.
Die Versandkosten hielten sich mit ca. €5 noch in Grenzen, zumal ich
noch drei NUCLEO-F446RE für je €10,70 mitbestellt hatte.
Besitzt jemand ein Datenblatt zu dem Display, so dass ich prüfen kann ob
die Timings stimmen?
Weiß hier jemand weiter oder hat dieses Problem auch schon gehabt?
STM32F7_Discovery_1.jpg
(180 KB)
STM32F7_Discovery_2.jpg
(150 KB)
STM32F7_Discovery_3.jpg
(240 KB)
STM32F7_Discovery_4.jpg
(230 KB)
STM32F7_Discovery_5.jpg
(240 KB)
STM32F7_Discovery_6.jpg
(230 KB)
