Cortex M7 zu überzüchtet

java kannst du natürlich benutzen wenn du ressourcen zu verschenken 
hast. wenn du nicht weißt wohin mit der rechenleistung und dem speicher 
nimm java, wenn du die 400Mhz sinnvoll nutzen willst nimm C.

Peter II schrieb:
> ich programmiere sogar 4 x 3GHZ und 16GB Ram mit C(++)

und dass ist noch lange nicht das limit ;) ich hatte auch schon 64 cores 
und 256GB Ram ;)

Manfred Dillberger schrieb:
> Ein 400MHz Microcontroller mit 32Megabyte flash? Was hat das denn noch
> mit Mikro zu tun? Ich habe keine Idee, wie ich diese Rechenleistung
> ausnutzen sollte.

Für Led-Blinki wirst du die Leistung nicht benötigen. Aber für 
Grafikanwendungen, komplexe Analysealgorithmen (z.B. Bilderkennung) 
u.v.a. kann es nicht schnell genug gehen.

> Kann man die noch in C programmieren oder wird hier z.B. Javascript
> (Ajax) sinnvoll? Wahrscheinlich braucht man ein komplettes
> Betriebssystem mit Treibern zur nutzung. Was kommt denn da in Frage?
> Linux?

Klar kann man die in C programmieren. Ich verwende selbst viel 
JavaScript, aber am uC wäre das reine Verschwendung von Ressourcen.

OS brauchst du eher, wenn du Peripherie o.ä. hast. Oder Multitasking, da 
kann es auch helfen.

Marc S. schrieb:
> java kannst du natürlich benutzen wenn du ressourcen zu
> verschenken
> hast. wenn du nicht weißt wohin mit der rechenleistung und dem speicher
> nimm java, wenn du die 400Mhz sinnvoll nutzen willst nimm C.

Java und JavaScript verwechseln - da merkt man wenigstens gleich, dass 
danach nur unqualifizierter Stammtisch folgt.

Manfred Dillberger schrieb:
> Ein 400MHz Microcontroller mit 32Megabyte flash? Was hat das denn noch
> mit Mikro zu tun? Ich habe keine Idee, wie ich diese Rechenleistung
> ausnutzen sollte.

Zum Beispiel mit micro python. Für ucLinux-on-a-chip reicht es mangels 
RAM leider immer noch nicht. SRAM ist noch zu teuer. Wenn mal Linux im 
144er Package läuft, hat die Fummelei ein Ende.

Christian J. schrieb:
> Gaga....

Was wäre denn dein Wunschcontroller?
Eine 10GHz Z80 mit 6850 als UART? ;-)

Jan Hansen schrieb:
> Marc S. schrieb:
>> java kannst du natürlich benutzen wenn du ressourcen zu
>> verschenken
>> hast. wenn du nicht weißt wohin mit der rechenleistung und dem speicher
>> nimm java, wenn du die 400Mhz sinnvoll nutzen willst nimm C.
>
> Java und JavaScript verwechseln - da merkt man wenigstens gleich, dass
> danach nur unqualifizierter Stammtisch folgt.

Java VM ist overhead den man sich nicht unbedingt leisten kann.


400 Mhz ist villeicht viel fürs LED blinken von uns hobby programmierern 
aber wir sind halt auch nicht die zielgruppe.

Christian J. schrieb:
> npn schrieb:
>
>> Wie heißt es so schön: "Datensicherung ist Mangel an Vertrauen!"
>> Da fällt mir ein, ich muß auch mal wieder ein Backup machen :-))
>
> Ich lebe noch, es geht mir gut, auch ohne

Das gilt für fast alles: Heizung, Haus/Wohnung, Arme, Niere, Genitalien 
usw usw.
Die Frage ist, will man ohne?

Christian J. schrieb:
> Der Entzug war schwer aber der
> Arzt sagte mir, dass ich drüber wegkommen werde.

Dann hoffen wir mal, dass dir dein Umzug nicht den Rest gibt. Denn wie 
heisst es doch: Dreimal umgezogen ist einmal abgebrannt. ;-)

Moby schrieb:
> Was ist denn ein drei Fußballfelder großer Z80 mit mindestend ebenso
> großer externer Peripherie für ein Vergleichsobjekt?

Dir fehlt etwas Kontext:
Beitrag "Re: Retro Fieber: Z80 oder 68000 ?"
Er fand ja sogar den harmlosen SIO für hoffnungslos kompliziert. ;-)

A. K. schrieb:
> Dir fehlt etwas Kontext:
> Beitrag "Re: Retro Fieber: Z80 oder 68000 ?"
> Er fand ja sogar den harmlosen SIO für hoffnungslos kompliziert. ;-)

Ich finde diese Vorratsdatenspeicherung des Forums ganz pöse. ;)

Moby schrieb:
> Da hat er doch recht. Nicht alles was älter ist ist zugleich auch
> einfacher. Ein AVR hingegen erreicht so ziemlich das Optimum von Nutzen
> und (Lern)Aufwand. Alles was danach kommt verschlechtert dieses
> Verhältnis fortlaufend wieder ;-)

Die Position des lokalen Optimums hängt hier unzweifelhaft von der 
geistigen Leistungsfähigkeit des Subjekts ab.

Detlef Kunz schrieb:
> Ich finde diese Vorratsdatenspeicherung des Forums ganz pöse. ;)

Bestes Rechtsstaatsprinzip: "Sie haben das recht zu schweigen, alles was 
sie sagen kann und wird gegen sie verwendet werden." ;-)

Ich kann das Problem des OPs nicht nachvollziehen.

Großer Flashspeicher und großes RAM machen einen Controller erstmal um 
kein Bit komplizierter. Da muss man also nichts Neues lernen.

Für den Entwickler ist das eine feine Sache, wenn eine Architektur 
dermaßen breit aufgestellt ist: man pickt sich einfach für jeden 
Anwendungsfall den passenden Controller raus.

Bei einem grafischen Display und angenommenen 800x480 bei 24 Bit 
Farbtiefe ist etwas Leistung schon sehr angenehm. Und man möchte auch 
nicht immer einen extra Grafikcontroller anbinden.

Hier laufen STM32F429 an eben diesen Displays und über zuviel Leistung 
kann ich mich nicht beklagen.

Klar sind die Referenzhandbücher dicker, aber man wird ja auch nicht 
gezwungen, alles auf einmal einzusetzen. Greift man sich immer nur die 
Gebiete raus, die man benötigt bzw. für die man gerade programmiert, 
dann sind das oft nur wenige Seiten.

Hobbyisten können die neuen ARMs doch in aller Ruhe "erobern" - es gibt 
da richtig viel zu entdecken :-)

Und für Leute, die damit ihr Geld verdienen, stellt sich die Frage nach 
zuviel Leistung sowieso nicht.

Moby schrieb:
> Umstieg ohne Not = gaga.

Wenn man erst Umsteigt, wenn man in Not ist ==> gaga  :)

m.n. schrieb:
> Wenn ich mich nicht verlesen habe, hat der ATMEL SAMx7 garkeinen
> Grafikcontroller.

Dem OP ging aber ganz allgemein um "zu viel" RAM, ROM, Leistung.

> Und der STM32F429 verschwendet ganz schön viele
> Beinchen dafür + ext. RAM

Das ist aber nicht dramatisch. Man muss ja nicht 24 Bit nehmen, wenn es 
nicht nötig ist. Die Beinchen braucht man sonst für den Grafikcontroller 
- und den F429 gibt es ja auch mit sehr vielen Beinchen :-)

> es sei denn, man schafft es, Bilder mit
> 800x480 bei 24 Bit Farbe im internen RAM unterzubringen ;-)

Das geht in der Tat, wir haben das gestern das erste Mal umgesetzt. 
Unser gesamter Grafikspeicher ist nun nur noch 100kB (2x50kB) groß.

Detlef Kunz schrieb:
> Wenn man erst Umsteigt, wenn man in Not ist ==> gaga  :)

Genau so ist es. Es ist sehr angenehm, wenn man nach oben hin immer noch 
genug Luft hat. Man kennt das ja vom Kunden: "das passt doch sicherlich 
noch rein" :-)

Moby schrieb:
> Die geistige Leistung des Subjekts sollte natürlich schon in der Lage
> sein, die Not bereits in der Ferne zu entdecken ;-)

Richtig - deswegen frühzeitig umsteigen. Je eher man das tut, umso mehr 
Zeit hat man für den Einstieg und umso leichter ist dieser.

Christian J. schrieb:
> Und dann kommt der böse EMP Impuls oder der Plattencrash und wie bei mir
> veschwinden 10 Jahre Softwaresammlung + 2000 Fotos im Nirvana. Oder das
> Handy fällt dir in den Dreck und du kennst nicht mal mehr die Nummer
> deiner Eltern, weil du die nur über einen Shortcut angerufen hast.
>
> Ein Grund warum ich ein stilechtes Moleskin Notizbuch habe und eine
> echtes Fotoalbum mit echten Bildern :-)

Und wenn dir die Hütte abbrennt? Ich hab Festplatten mit meinen Backups 
an 3 verschiedenen Orten im halben Land, das geht mit Fotoalben nicht.

Damit werden halt auch Anwendungen machbar, an die bisher nicht zu 
denken war. Wo heute vielleicht ein kleiner Mikrocontroller die Funktion 
steuert, hat man morgen ein Linux mit WLAN und Webserver, wo man 
jederzeit den Status abfragen kann. Waschmaschine oder Backofen 
beispielsweise. Warum soll man den Backofen oder die Waschmaschine über 
ein teures Tastenfeld und kleines Display steuern, und nicht vom Tablet 
über eine Webapplikation? Wenn man's richtig macht, ist das günstiger 
und komfortabler.

Guten Abend,

Vor ein paar Jahren fing ich an mit M3 STM32s zu arbeiten weil wir in 
der Firma ein Projekt anfingen wo wir die Rechenleistung brauchten.

Ich machte mir am Anfang meine eigene I2C Treiber. Hat auch einigermaßen 
gut funktioniert. Aber es war nicht 100%ig. Später adoptierte ich die 
AN1284 I2C Treiber weil die von ST als optimal vorgeschlagen wurden. 
Alles funktionierte bestens. Was mich aber am Datenblatt (User Manual) 
sehr störte war die meiner Meinung nach recht bedürftige Beschreibung 
und Dokumentation des I2C Blocks. Als ich anfing die Routinen der I2C 
AN1284 durchzugehen fragte ich mich wie man als Einsteiger das Wissen 
bekommt so etwas wie die AN1284 Routinen überhaupt zu konzipieren. Dazu 
ist meiner Meinung nach einfach nicht genug Information im Datenblatt. 
Es gibt keine State Diagrams die die Funktion der I2C Hardware komplett 
genug beschreiben. Es ist ja so dass man zum Beispiel zwischen den 
einzelnen Ablaufschritten die Status Register lesen muß um einen 
einwandfreien Ablauf der I2C Statemachine in der HW richtig 
funktionieren zu lassen. Wenn man das nicht macht dann gibt es 
Schwierigkeiten in der HW-Statemachine. Sicher, es ist ein 
Ablaufdiagramm im Datenblatt, aber irgendwie gehört meiner Meinung nach 
mehr Applicationsinformation hinein. Dem I2C Block gebührt meiner 
Meinung nach eine Appnote die diesen Block komplett beschreibt.

Könntet ihr so ohne weiteres eine äquivalente Treiberfunktion mit den 
publizierten Resourcen von ST schreiben die funktionell identisch wäre? 
Sicher, nach dem Durchgehen der AN1284 Routinen hat das nachhinein schon 
Sinn.

Ich masse mir ja nicht an ein Experte zu sein, aber in diesem Fall bin 
ich der Meinung die Beschreibung ist sehr bedürftig. Sie wäre nur für 
einen richtigen Experten der die Innereien sowieso schon 100%ig kennt 
zur Referenz ausreichend. Es würde mich interessieren ob es Euch ähnlich 
beim Gebrauch der I2C Innereien ging. Die Tatsache, dass ST AN1284 
rausbrachte scheint ja irgendwie treffend zu sein. Wie denkt Ihr 
darüber?


Mfg,
Gerhard

@Gerhard: Ist das nicht besser in einem eigenen Thread aufgehoben?

Hier ist "zuviel Leistung" das Thema, eher nicht "dürftige Beschreibung" 
- auch wenn es um STM32/Cortexe geht.

Moby schrieb:
> P. M. schrieb:
>> Damit werden halt auch Anwendungen machbar, an die bisher nicht zu
>> denken war. Wo heute vielleicht ein kleiner Mikrocontroller die Funktion
>> steuert, hat man morgen ein Linux mit WLAN und Webserver, wo man
>> jederzeit den Status abfragen kann. Waschmaschine oder Backofen
>> beispielsweise. Warum soll man den Backofen oder die Waschmaschine über
>> ein teures Tastenfeld und kleines Display steuern, und nicht vom Tablet
>> über eine Webapplikation? Wenn man's richtig macht, ist das günstiger
>> und komfortabler.
>
> Das lässt sich doch auch locker 8-bittig realisieren. Netzwerkanbindung
> via 3€ China ESP8266.

Ein Linux eher nicht - und man hat einen weiteren Chip/Hersteller im 
Boot - will man nicht.

(wobei man aber die Frage stellen sollte, ob ein Linux hier wirklich 
sinnvoll ist.)

Chris D. schrieb:
> @Gerhard: Ist das nicht besser in einem eigenen Thread aufgehoben?
>
> Hier ist "zuviel Leistung" das Thema, eher nicht "dürftige Beschreibung"
> - auch wenn es um STM32/Cortexe geht.

Ja. Ich hatte schon ein ganz schlechtes Gewissen:-)

Grüße,
Gerhard

123 schrieb:
> Gerhard O. schrieb:
>> Was mich aber am Datenblatt (User Manual)
>> sehr störte war die meiner Meinung nach recht bedürftige Beschreibung
>> und Dokumentation des I2C Blocks.
>
> Das Programming Manual gibt für gewöhnlich Aufschluss über die Nutzung,
> während das Datenblatt nur die Daten gibt. Aber ja generell find ich ST
> Datenblätter generell sehr bedürftig.

Ich bezog mich prinzipiell auf das User Manual RM0008

Gruß,
Gerhard

m.n. schrieb:
> Chris D. schrieb:
>>> es sei denn, man schafft es, Bilder mit
>>> 800x480 bei 24 Bit Farbe im internen RAM unterzubringen ;-)
>>
>> Das geht in der Tat, wir haben das gestern das erste Mal umgesetzt.
>> Unser gesamter Grafikspeicher ist nun nur noch 100kB (2x50kB) groß.
>
> Das geht aber nicht ohne Kompromisse; ich vermute eine sw-Darstellung.

Da vermutest Du falsch ;-)

Nie einen C64 programmiert?

Tipp: Wie stellte man mehr als acht Sprites auf einmal dar?

m.n. schrieb:
> Chris D. schrieb:
>> Da vermutest Du falsch ;-)
>>
>> Nie einen C64 programmiert?
>
> Nein, der kam nach meiner Zeit ;-)

;-)

> Ich sollte wohl das Datenblatt des ..429 näher ansehen.

Ok, etwas Offtopic - aber das Prinzip ist eigentlich recht einfach und 
es zeigt auch, wofür man Rechenleistung benötigen kann - passt also doch 
wieder etwas in den Thread ;-)

Man arbeitet (wie normalerweise auch) mit zwei Puffern, die aber 
natürlich im Falle des 429 kleiner als der Bildschirm sein müssen, da 
der Controller nur 256kB an Bord hat.

Der LTDC hat eine schöne Interruptquelle: den Rasterzeileninterrupt.
Diese Unterbrechung wird immer dann ausgelöst, wenn die aktuell 
ausgegebene Zeilennummer der im LTDC_LIPCR entspricht.

Man macht nun nichts anderes, als bspw. jeweils 50 Zeilen abzuwarten und 
dann in der ISR den Puffer jeweils umzuschalten und die neue 
Zeilennummer für den nächsten Interrupt zu setzen. Während dieser Puffer 
ausgegeben wird, kann man dann den Inhalt für die darauffolgenden 50 
Zeilen berechnen usw.

Natürlich muss der 429 dabei ständig die Grafiken im jeweilgen Bereich 
neu berechnen und für Videoausgaben etc. ist das Verfahren wohl eher 
nichts, aber für viele Anwendungen ist das kein Problem. Man lässt die 
Berechnung einfach in einer eigenen Task hoher Priorität laufen, dann 
bleibt noch genug Zeit für anderes.

Wenn man dann noch mit der Palette des LTDC arbeitet, benötigt man auch 
nur noch ein Byte pro Pixel und hat doch 24 Bit Farbraum zur Verfügung. 
Für normale Touchscreenanwendungen reicht das locker aus.

Ob es dem Auge auffällt, wenn man bei hoher Auslastung bspw. einfach 
einen der 60 Frames pro Sekunde komplett weglässt, müsste man sehen.

Und schwupps ist der externe RAM unnötig und man hat deutlich mehr 
Ausgänge zur Verfügung :-)

Beim C64 wurde das auch genau so gemacht. So konnte man in jedem Bereich 
acht Sprites darstellen, die dann nur entsprechend umgeschaltet wurden.

P.S.: Ich hab einfach mal ein Bild meines gestrigen Erstversuchs 
angehängt. Der zeigt bisher freilich nur ein Testbild - aber das Prinzip 
funktioniert flackerfrei - man sieht keinen Unterschied zur Ausgabe mit 
dem externen RAM. Sorry für die Qualität - ist vom Smartphone bei 
Glühlampenlicht aufgenommen ;-)

Gerhard O. schrieb:
> Sicher, nach dem Durchgehen der AN1284 Routinen hat das nachhinein schon
> Sinn.

Sollte AN2824 sein. STM32F10xxx I2C optimized examples

Danke. Chris

Gerhard

Chris D. schrieb:
> Und schwupps ist der externe RAM unnötig und man hat deutlich mehr
> Ausgänge zur Verfügung :-)

Das ist m.E. der wirkliche Pferdefuss, zumindest in den LQFP100 
Gehäusen. Die Anschlüsse (und man siehts ja an Chris' Aufbau) sind wie 
Kraut und Rüben über das Gehäuse verteilt - den Jungs bei STM müsste man 
mal ihre Drogen entziehen.
Allerdings kann man ja skalieren und nach dem Prototyp auf das richtige 
Gehäuse (gibt ja LQFP176 oder sogar BGA216) umsteigen, dann entspannt 
sich die AF Belegung wieder.

Matthias Sch. schrieb:
> Die Anschlüsse (und man siehts ja an Chris' Aufbau) sind wie
> Kraut und Rüben über das Gehäuse verteilt - den Jungs bei STM müsste man
> mal ihre Drogen entziehen.

Die sind völlig nüchtern. Deren Chips gibt es in den verschiedensten 
Pincounts mit dem gleichen Inhalt. Da folglich bei kleineren Gehäuse 
Pins weggelassen werden, müssen sich die wegzulassenden Pins der 
Bondierung wegen einigermassen gleichmässig über die Kanten verteilen 
und auch die AF Zuordnung ballt sich folglich ein wenig auf den übrig 
bleibenden Pins.

Matthias Sch. schrieb:
> Chris D. schrieb:
>> Und schwupps ist der externe RAM unnötig und man hat deutlich mehr
>> Ausgänge zur Verfügung :-)
>
> Das ist m.E. der wirkliche Pferdefuss, zumindest in den LQFP100
> Gehäusen. Die Anschlüsse (und man siehts ja an Chris' Aufbau) sind wie
> Kraut und Rüben über das Gehäuse verteilt - den Jungs bei STM müsste man
> mal ihre Drogen entziehen.

Das stimmt - dadurch, dass man für die LTDC-Ausgänge auch keine 
Alternativen hat, blockiert das schon einiges. Unschön - aber wir sind 
schon froh, dass es den LTDC endlich gibt. Zusammen mit Chrome Art kann 
man jetzt shcon einiges machen. Und der externe Grafikcontroller würde 
auch ein paar Pins belegen.

> Allerdings kann man ja skalieren und nach dem Prototyp auf das richtige
> Gehäuse (gibt ja LQFP176 oder sogar BGA216) umsteigen, dann entspannt
> sich die AF Belegung wieder.

Ja - für Anwendungen mit externem RAM werden wir auf jeden Fall den 
LQFP176 oder gar LQFP208 nehmen. An BGA traue ich mich erst, wenn unsere 
Dampfphasenlötanlage komplett ist ;-)

A. K. schrieb:
> Die sind völlig nüchtern. Deren Chips gibt es in den verschiedensten
> Pincounts mit dem gleichen Inhalt. Da folglich bei kleineren Gehäuse
> Pins weggelassen werden, müssen sich die wegzulassenden Pins der
> Bondierung wegen einigermassen gleichmässig über die Kanten verteilen
> und auch die AF Zuordnung ballt sich folglich ein wenig auf den übrig
> bleibenden Pins.

Schon klar - aber bei den anderen Modulen gibt es zumindest die 
Möglichkeit, alternative Pins zu wählen. Beim LTDC leider nicht.

A. K. schrieb:
> ein wenig auf den übrig
> bleibenden Pins.

Das hast du aber nett ausgedrückt, vor allem das 'ein wenig' :-) Das ist 
jedenfalls beim F429 Disco so bescheuert, das du nicht einen einzigen 
8-bit Port am Stück hast - 5 sind das höchste der Gefühle. Chris 
Radikallösung, das LCD einfach runterzurupfen, kann ich da gut 
verstehen, hehehe. Gut, bei mir ist das F429 Disco Board mittlerweile 
ein kleines Handheld Oszi, das geht mit der Pinbelegung gerade so auf. 
Aber mehr als 2 ADC Kanäle? Pustekuchen...

m.n. schrieb:

> Da ich Dich als pragmatischen Menschen bezüglich Kosten-Nutzen-Stückzahl
> in Erinnerung habe, wundert es mich, daß Du wegen ein paar Euro,50
> 'Würmer' in die Software einbauen möchtest. Andererseits verstehe ich
> schon den Spaß, den ..429 auszureizen. Die div. internen Busse laden ja
> geradezu ein, SRAM1, SRAM3 und CCM parallel zu nutzen.

Eben, eben :-)

Aber wie Du schon sagst, war das eher eine Machbarkeitsstudie als auf 
eine konkrete Anwendung gemünzt.

Davon abgesehen, dass man natürlich mehr Rechenzeit verbrät, haben wir 
hier das Problem, dass sich diese Art der Ansteuerung nur mit größerem 
Aufwand in bereits bestehende RTOS (z.B. NuttX) integrieren lässt, da 
diese bei ihren Grafikmodulen praktisch immer von einem "normalen" 
Framebuffer ausgehen.

> Und wenn man mit einer begrenzten Anzahl statischer Bilder im Flash
> hinkommt, hat Deine Lösung ja auch ihren Charme.
>
> Nur, sobald die Anwendung z.B. mehrsprachig sein soll und dynamisch
> skalierte Kurven nebst Beschriftung dargestellt werden müssen, kommt man
> um einen kompletten Bildspeicher nicht umhin.
> Persönlich nutzte ich dann lieber die Leistung des Prozessors, den
> Bildaufbau zügig zu erledigen, als Bildfragmente herumzuschieben.

Ich habe gerade nochmal überlegt. Ist das wirklich so?

Eigentlich ist diese Ansteuerung doch sogar umso effizienter, je 
dynamischer der Bildaufbau ist, denn: wenn ich sowieso den Inhalt sehr 
oft neu berechnen/erstellen muss, dann ist es fast egal, ob ich das 
scheibchenweise tue oder in einem.

Ich hab oben geschrieben, dass es bei Videos nicht so gut ist - das ist 
natürlich Unsinn: gerade wenn ich praktisch in jedem Frame neu 
Aufbauen muss, sind die Nachteile der "Scheibchenmethode" am geringsten.

Das schlechteste ist bspw. eine Touchscreenoberfläche mit irgendwelchen 
Buttons, auf der fast nichts passiert.

Mehrsprachigkeit ist doch eher eine Frage der größe des Flashspeichers, 
oder?

> Chris D. schrieb:
>> Wenn man dann noch mit der Palette des LTDC arbeitet, benötigt man auch
>> nur noch ein Byte pro Pixel und hat doch 24 Bit Farbraum zur Verfügung.
>> Für normale Touchscreenanwendungen reicht das locker aus.
>
> Mir reichen schon < 8 Farben!
> Das kann man dann je nach 'Beinfreiheit' des Gehäuses entscheiden. ;-)

Ja. Für unsere Projekte werden wir wohl den 176er und externes RAM 
nehmen. Platz müssen wir nicht sparen (die Displaygröße erfordert ja 
schon gewisse Gehäuseabmessungen), ebensowenig auf den Preis achten.

Aber für Leute mit einem STM32F429-DISCO und Pin-Not könnte das eine 
Lösung sein: einfach das Ram runterlöten udn schon hat man reichlich 
Pins mehr :-)