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
Angehängte Dateien:
-
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
Interessantes Teil, danke für die Info! Allerdings finde ich keine Bezugsquelle... Wo bekommt man denn dieses Spielzeug her?
Digikey hat es schon gelistet und ruft 50,43€ auf. Allerdings 0 verfügbar. Dann sollte es aber auch in den nächsten Tagen bei Farnell auftauchen.
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!)
:
Bearbeitet durch User
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.
Was wurde denn auf dem Hands-On Seminar in München zum Thema Betriebssystem gesagt? FreeRTOS war ja nur ein Beispiel. Hat schon mal jemand von Euch mit STM32CubeF7 ein neues Projekt aufgesetzt? http://www.st.com/web/en/catalog/tools/PF261909 http://www.freertos.org/FreeRTOS-Plus/BSP_Solutions/st/STM32Cube.html Geht das gut, oder nervt das eher?
Ü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.
Na ja, ich würde das Ganze schon anhören. Nur sind meine Englischkenntnisse halt eher durchschnittlich (also nicht besonderes)
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)
Das Board gefällt mir auch. Sieht nach einer guten Basis für ein (Car-) Audio DSP aus :D
Das Board wird wahrscheinlich auch auf Embedded World 2016 geben. Ich nehme an, dass Atmel auch bald so ein Cortex M7 Board rausbringt.
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
und noch der Link zum Manual: http://www.st.com/st-web-ui/static/active/en/resource/technical/document/user_manual/DM00188496.pdf?s_searchtype=keyword
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
Hat jemand eine Registerbeschreibung zum verwendeten Rockteck RK043FN48H-CT672B Display?
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?
:
Bearbeitet durch User
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!
Torsten C. schrieb: > Ein STM32F7 NUCLEO muss her! F7 ist nicht mit 64 Pins geplant. Damit wir es wohl kaum ein Nucleo geben...
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.
Torsten C. schrieb: > Was ich damit sagen will: Ein STM32F7 ohne Demo-Peripherie muss her! Mach doch! Der STM32F746VGT6 ist bei Mouser auf Lager.
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.
:
Wiederhergestellt durch Admin
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 ;)
Das Nucleo Board ist Q4/2015 angekündigt: http://www.st.com/web/en/resource/sales_and_marketing/promotional_material/brochure/BRSTM32F70515.pdf
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)
:
Bearbeitet durch User
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.
Gibt es irgendwo die Firmware die werkseitig aufgespielt ist? Im Cube Ordner ist nur etwas für das Eval vorhanden?
Farnell hat grad knapp 500 auf Lager, ich zwei. Die Firmware soll es hier geben: https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Discovery/Attachments/14145/STM32F746G-DISCO-V1.0.0.zip hab aber noch nicht verglichen.
http://www.emcraft.com/products/413#starter-kit am besten gleich das ucLinux lauffähig machen für das STM32F7 Discovery Board http://www.emcraft.com/component/jdownloads/view.download/74/754
Angehängte Dateien:
-
STM32F746G-Disco_Front.jpg
170 KB
oder mal mit STM32CubeMX reinschnuppern. Digi hat geliefert. Wenn das Wetter nicht so geil wäre ... Gruß, dasrotemopped.
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...
:
Bearbeitet durch User
Angehängte Dateien:
-
STM32F745.JPG
51 KB
Oliver R. schrieb: > Farnell hat grad knapp 500 auf Lager, ich zwei. > Die Firmware soll es hier geben: > https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Discovery/Attachments/14145/STM32F746G-DISCO-V1.0.0.zip > hab aber noch nicht verglichen. Interessant was da auf dem Link steht an Dokumentation. http://de.farnell.com/stmicroelectronics/stm32f746g-disco/dev-kit-discovery-cortex-m7-stm32f7/dp/2480961?ost=stm32f7 Daraus: Es soll einen STM32F745 ohne LCD geben - wenn man das googelt kommt man zwar zu einem STM-Link aber der ist tot. rgds
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
Es gibt ein Update der STM32CubeF7 Software: v.1.1.0 http://www.st.com/web/en/catalog/tools/PF261909# Nun wird auch das STM32F746-Discovery Board unterstützt :)
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 ?
hanspeter schrieb: > welche kostenlose Toolchain gibt es den im Moment für den M7 ? Ich habe diese probiert: http://www.openstm32.org/forumthread172 Funktioniert (getestet mit dem F746-Disco Board).
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 ...
uwe hat die pinbelegung und eine kleine beschreibung für die openstm32 toolchain geschrieben www.mikrocontroller.bplaced.net
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 ;-)
m.n. schrieb: > Interessant, für den Nachbau läßt dieser Umstand Bastlers Herz > sicherlich höher schlagen ;-) Nicht als Finepitch aber ... rgds
>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
Angehängte Dateien:
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ß
sorry, offtopic: @6a66 grübel... web.de 03.07.2015 13:12 web.de 07.07.2015 21:22
@ 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!
Ich bezweifel ganz stark, dass das "Nö" von demselben Tectu wie weiter oben stammt...
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?
SB 14-17 entfernen und Leitungen anlöten erscheint mir die einzige Moeglichkeit, ist aber nicht besonders praktikabel...
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!
Angehängte Dateien:
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.
:
Bearbeitet durch User
Es gibt auch noch andere interessante Informationen auf dieser Webseite, auf die ich mehr zufällig gestoßen bin: http://www.emcu.it/STM32F7/STM32F7xx.html
STM32F7PreUser schrieb: > für alle die nicht am Workshop teilnehmen > > http://www.emcu.it/STM32F7/STM32F7_workshop_ORIGINALI.zip Danke für die Zip, aber wie lautet das Password? Grüße Dirk
da hilft wohl nur eine Anfrage an: emcu.info@gmail.com ich weiß es bisher auch nicht.
Besitzt jemand ein Datenblatt zu dem Display? Ich finde auf der Herstellerseite nichts.. Alternativ auch die Timings.
René K. schrieb: > Besitzt jemand ein Datenblatt zu dem Display? Ich finde auf der > Herstellerseite nichts.. > Alternativ auch die Timings. Bei den Beispielen im STM32CubeF7 stehen die Timings drin. http://www.st.com/web/en/catalog/tools/PF261909
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
So, jetzt auch mit Account eingeloggt damit dieses getrolle aufhört. Was für ein Kindergarten hier! Ich verwende das STM32F7 Discovery board ohne IDE, ohne library oder sonstiges. Texteditor + make reicht für den Anfang. Wenn ich debuggen muss nehme ich Em::Blocks her. René K. schrieb: > Besitzt jemand ein Datenblatt zu dem Display? Ich finde auf der > Herstellerseite nichts.. > Alternativ auch die Timings. Das Display ist ein Rocktech RK043FN48H. Die timings habe ich aus dem Beispielcode von ST entnommen: https://bitbucket.org/Tectu/ugfx/src/8b60b516231dee99f9e5df6b3398b4279568f6bb/boards/base/STM32F746-Discovery/board_STM32LTDC.h?at=master#board_STM32LTDC.h-15
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).
:
Bearbeitet durch User
Ich bin echt ratlos. Ich habe jetzt mal im ST-Forum nachgefragt. Hoffentlich kann mir/uns da jemand weiter helfen: https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fSTM32F7xx%20I2C%20bus%20frequency%20too%20high&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&TopicsView=https%3A%2F%2Fmy%2Est%2Ecom%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2FAllItems%2Easpx¤tviews=3
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:
1 | git clone git://repo.or.cz/openocd.git openocd-stm32f7 |
2 | cd openocd-stm32f7 |
3 | git fetch http://openocd.zylin.com/openocd refs/changes/54/2754/2 && git checkout FETCH_HEAD |
4 | git fetch http://openocd.zylin.com/openocd refs/changes/55/2755/4 && git cherry-pick FETCH_HEAD |
5 | ./bootstrap |
6 | ./configure --enable-stlink |
7 | make
|
openocd starten:
1 | cd tcl |
2 | ../src/openocd -f board/stm32f7discovery.cfg |
Hat zufällig schon jemand die originale Demonstration als luna Projekt erstellt?
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...
:
Bearbeitet durch User
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:
1 | mkdir workspace-F7-ugfx |
2 | cd workspace-F7-ugfx |
Dateien holen:
1 | git clone https://bitbucket.org/Tectu/ugfx.git |
Libs vorbereiten:
1 | mkdir -p STM32Cube_FW_F7_V1.1.0/Drivers/CMSIS/Device/ST/STM32F7xx/ |
2 | |
3 | cp -r ~/STM32Cube/Repository/STM32Cube_FW_F7_V1.1.0/Drivers/CMSIS/Device/ST/STM32F7xx/* STM32Cube_FW_F7_V1.1.0/Drivers/CMSIS/Device/ST/STM32F7xx/ |
4 | |
5 | mkdir -p STM32Cube_FW_F7_V1.1.0/Drivers/STM32F7xx_HAL_Driver/Inc/ |
6 | mkdir -p STM32Cube_FW_F7_V1.1.0/Drivers/STM32F7xx_HAL_Driver/Src/ |
7 | |
8 | cp -r ~/STM32Cube/Repository/STM32Cube_FW_F7_V1.1.0/Drivers/STM32F7xx_HAL_Driver/Inc/* STM32Cube_FW_F7_V1.1.0/Drivers/STM32F7xx_HAL_Driver/Inc/ |
9 | cp -r ~/STM32Cube/Repository/STM32Cube_FW_F7_V1.1.0/Drivers/STM32F7xx_HAL_Driver/Src/* STM32Cube_FW_F7_V1.1.0/Drivers/STM32F7xx_HAL_Driver/Src/ |
10 | |
11 | cp -r ~/STM32Cube/Repository/STM32Cube_FW_F7_V1.1.0/Drivers/CMSIS/Include STM32Cube_FW_F7_V1.1.0/Drivers/CMSIS/ |
In das Projektverzeichnis wechseln:
1 | cd ugfx/boards/base/STM32F746-Discovery/example_raw32/ |
Makefile anpassen:
1 | $ gedit Makefile |
2 | |
3 | GFXLIB = ../../../../../ugfx |
4 | CMSIS = $(GFXLIB)/../STM32Cube_FW_F7_V1.1.0/Drivers/CMSIS/ |
5 | HAL = $(GFXLIB)/../STM32Cube_FW_F7_V1.1.0/Drivers/STM32F7xx_HAL_Driver/ |
Projekt bauen:
1 | make
|
Cmpiliert schon mal, das Ergebnis ist aber noch ungetestet. Für mich mache ich erst noch ein eclipse Projekt daraus...
hp-freund schrieb: > Vielleicht ist ja texane bald soweit? :) Kurze Info: Bei Texane sind die Patches für den STM32F7 drin... https://github.com/texane/stlink
Touchcontrollerdatenblatt: http://pan.baidu.com/wap/album/file?uk=3910247274&album_id=2986509354423377011&fsid=2276800196
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.
:
Bearbeitet durch User
STM32F7PreUser schrieb: > für alle die nicht am Workshop teilnehmen > > http://www.emcu.it/STM32F7/STM32F7_workshop_ORIGINALI.zip Na toll. Verrätst du uns auch das Passwort oder haben wir alle 700MB umsonst runtergeladen?
STM32F7PreUser schrieb: > da hilft wohl nur eine Anfrage an: > > emcu.info@gmail.com > > ich weiß es bisher auch nicht. Darauf hatte ich schon geantwortet.
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
gerade das gefunden: https://www.youtube.com/watch?v=vuX6qwvs5Gs schaut zumindest interessant aus ...
7856ujtzuitzu schrieb: > achso.. vergessen.. > > https://github.com/EmcraftSystems funktioniert gut, allerdings werden u.a. das LCD und der QSPI nicht unterstützt
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
Angehängte Dateien:
-
KK32F7-Testboard-LP1.jpg
370 KB -
KK32F7-Testboard-LP2.jpg
400 KB -
KK32F7-Testboard-LP3.jpg
230 KB
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
Angehängte Dateien:
-
KK32F7_Board_Display1.jpg
110 KB -
KK32F7_Board_Display2.jpg
230 KB
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
Angehängte Dateien:
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.
ich habe den "CycloneTCP dual IPv4/IPv6 stack" auf meinen Board implementiert. Läuft ohne Probleme. http://www.oryx-embedded.com/cyclone_tcp.html
Mecrisp Stellaris FORTH 2.2.1 läuft jetzt auch auf dem STM32F746g-Disco. Hier : http://sourceforge.net/projects/mecrisp/files/mecrisp-stellaris-2.2.1.tar.gz/download
:
Bearbeitet durch User
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
Hallo Steffen, danke für das Angebot, aber 44€ sind schon mal eine Ansage. VG Pete
@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:
1 | /* Assert display enable LCD_DISP pin */
|
2 | HAL_GPIO_WritePin(LCD_DISP_GPIO_PORT, LCD_DISP_PIN, GPIO_PIN_SET); |
3 | |
4 | /* Assert backlight LCD_BL_CTRL pin */
|
5 | HAL_GPIO_WritePin(LCD_BL_CTRL_GPIO_PORT, LCD_BL_CTRL_PIN, GPIO_PIN_SET); |
Dieser wird von CubeMX NICHT automatisch mitgeneriert. Also es hat alles funktioniert, außer der enable pin, sowie das backlight -.-
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?
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
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.
edit: generell sind irgendwie alle Peripherrieregister mit 0 beschrieben (also alles ab 0x40000000 ...)
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?
1 | SECTIONS |
2 | {
|
3 | ... |
4 | |
5 | XXXX : |
6 | {
|
7 | YYY |
8 | YYY |
9 | YY |
10 | }SDRAM |
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
Angehängte Dateien:
-
IMG_3995.jpg
240 KB -
IMG_3996.jpg
230 KB -
IMG_3997.jpg
250 KB -
IMG_3998.jpg
240 KB -
IMG_3999.jpg
240 KB -
IMG_4001.jpg
220 KB -
IMG_4002.jpg
230 KB
Bei interesse, hier das demontierte Display
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?
1 | #include "stm32f7xx.h" |
2 | #include "stm32746g_discovery.h" |
3 | #include "stm32746g_discovery_lcd.h" |
4 | |
5 | int main(void) |
6 | {
|
7 | |
8 | HAL_Init(); |
9 | BSP_LED_Init(LED1); |
10 | BSP_LCD_Init(); |
11 | |
12 | BSP_LCD_SetBackColor(LCD_COLOR_DARKGREEN); |
13 | BSP_LCD_DisplayOn(); |
14 | |
15 | |
16 | while(1) |
17 | {
|
18 | BSP_LED_Toggle(LED1); |
19 | HAL_Delay(200); |
20 | }
|
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.
Ich habe mir vor kurzem dieses Board geholt. Allerdings gibt es hierbei einige Dinge, welche ich nicht verstehe. Ich habe als Vorlage das "Hello World" Example mit EmWin verwendet. Dieses Beispiel funktioniert. Zeichne ich einige Kreise und Buttons funktionieren diese auch tadellos. Allerdings werden Bilder mit alpha Werten nicht richtig angezeigt. Außerdem sind Dialoge, welche mittels dem GUI Builder erstellt wurden irgendwie seltsam verschwommen. Für Bilder bitte auf folgenden Link klicken (habe das Problem bereits im STM Forum gepostet): https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2femWin%20Problem%20with%20STM32F746%20Disco%20board&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=30 Eine Antwort besagt, ich solle das Interface prüfen. Folgende Treiber wurden wie im Beispiel verwendet:
1 | #define COLOR_CONVERSION_0 GUICC_M8888I
|
2 | #define DISPLAY_DRIVER_0 GUIDRV_LIN_32
|
Auch die Timings habe ich nicht verändert:
1 | /* Set LCD Timings */
|
2 | hltdc.Init.HorizontalSync = 40; |
3 | hltdc.Init.VerticalSync = 9; |
4 | hltdc.Init.AccumulatedHBP = 53; |
5 | hltdc.Init.AccumulatedVBP = 11; |
6 | hltdc.Init.AccumulatedActiveH = 283; |
7 | hltdc.Init.AccumulatedActiveW = 533; |
8 | hltdc.Init.TotalHeigh = 285; |
9 | hltdc.Init.TotalWidth = 565; |
10 | |
11 | /* background value */
|
12 | hltdc.Init.Backcolor.Blue = 0; |
13 | hltdc.Init.Backcolor.Green = 0; |
14 | hltdc.Init.Backcolor.Red = 0; |
15 | |
16 | /* Polarity */
|
17 | hltdc.Init.HSPolarity = LTDC_HSPOLARITY_AL; |
18 | hltdc.Init.VSPolarity = LTDC_VSPOLARITY_AL; |
19 | hltdc.Init.DEPolarity = LTDC_DEPOLARITY_AL; |
20 | hltdc.Init.PCPolarity = LTDC_PCPOLARITY_IPC; |
21 | hltdc.Instance = LTDC; |
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?
:
Bearbeitet durch User
Ich habe den Fehler gefunden!! Die LCDconf.c aus dem Exampel bindet den falschen Treiber ein. Der verwendete Treiber ist dieser:
1 | #define COLOR_CONVERSION_0 GUICC_M8888I
|
2 | #define DISPLAY_DRIVER_0 GUIDRV_LIN_32
|
Der richtige Treiber lautet jedoch:
1 | #define COLOR_CONVERSION_0 GUICC_M888
|
2 | #define DISPLAY_DRIVER_0 GUIDRV_LIN_24
|
Außerdem muss folgendes Unterprogramm angepasst werden:
1 | static inline U32 LCD_LL_GetPixelformat(U32 LayerIndex) |
2 | {
|
3 | if (LayerIndex == 0) |
4 | {
|
5 | return LTDC_PIXEL_FORMAT_ARGB8888; |
6 | }
|
7 | else
|
8 | {
|
9 | return LTDC_PIXEL_FORMAT_ARGB1555; |
10 | }
|
11 | }
|
zu:
1 | static uint32_t LCD_LL_GetPixelformat(uint32_t LayerIndex) |
2 | {
|
3 | const LCD_API_COLOR_CONV * pColorConvAPI; |
4 | |
5 | if (LayerIndex >= GUI_NUM_LAYERS) |
6 | {
|
7 | return 0; |
8 | }
|
9 | pColorConvAPI = layer_prop[LayerIndex].pColorConvAPI; |
10 | |
11 | if (pColorConvAPI == GUICC_M8888I) |
12 | {
|
13 | return LTDC_PIXEL_FORMAT_ARGB8888; |
14 | }
|
15 | else if (pColorConvAPI == GUICC_M888) |
16 | {
|
17 | return LTDC_PIXEL_FORMAT_RGB888; |
18 | }
|
19 | else if (pColorConvAPI == GUICC_M565) |
20 | {
|
21 | return LTDC_PIXEL_FORMAT_RGB565; |
22 | }
|
23 | else if (pColorConvAPI == GUICC_M1555I) |
24 | {
|
25 | return LTDC_PIXEL_FORMAT_ARGB1555; |
26 | }
|
27 | else if (pColorConvAPI == GUICC_M4444I) |
28 | {
|
29 | return LTDC_PIXEL_FORMAT_ARGB4444; |
30 | }
|
31 | else if (pColorConvAPI == GUICC_8666) |
32 | {
|
33 | return LTDC_PIXEL_FORMAT_L8; |
34 | }
|
35 | else if (pColorConvAPI == GUICC_1616I) |
36 | {
|
37 | return LTDC_PIXEL_FORMAT_AL44; |
38 | }
|
39 | else if (pColorConvAPI == GUICC_88666I) |
40 | {
|
41 | return LTDC_PIXEL_FORMAT_AL88; |
42 | }
|
43 | while (1); |
44 | }
|
Angehängte Dateien:
-
P1000849.jpg
100 KB -
P1000946.jpg
80 KB
Was kann man mit dem STM32F7 Disco anstellen? In meiner Anwendung dient es als Bedien- und Anzeigebaugruppe für einen kleinen Kurzwellentransceiver (Amateurfunk). Mit der Software- Bibliothek von Uwe Becker hatte ich eine gute Grundlage für meine Arbeit. Nun ist das Gerät einsatzfähig. Die wichtigste Baugruppe ist ein Red Pitaya. Links: http://www.wkiefer.de/x28/Red%20Pitaya.htm http://www.qrpforum.de/index.php?page=Thread&postID=85340#post85340 http://mikrocontroller.bplaced.net/wordpress/?page_id=5264 Die Software für STM32F7 wurde übrigens mit Eclipse und der GCC- Maschinerie entwickelt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.