Habe gerade diesen Artikel über die neuen Cortex M7 gefunden: http://www.elektroniknet.de/halbleiter/mikrocontroller/artikel/115300/ 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. 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?
Manfred Dillberger schrieb: > Kann man die noch in C programmieren oder wird hier z.B. Javascript > (Ajax) sinnvoll? ich programmiere sogar 4 x 3GHZ und 16GB Ram mit C(++) Müsse auch nicht das in C eine Begrenzung der CPU Leistung gibt.
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.
Gleiches im Embeddedbereich. Sobald es aufwendiger wird sind auch 600MHz und mehrere MB internem Flash eine Limitierung. Dazu kommt dann noch externes RAM/Flash/FRAM. Ob nun mit Linux oder eigenem RTOS. Mittlerweile läuft halt auch ziemlich viel auf den Controllern selbst was vor Jahren noch utopisch war.
Bin schon mit dem M4 derzeit überfordert.... bzw. muss die Treppe noch erstiegen werden :-(
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.
Ist doch das gleiche mit den A20 "Mikrocontrollern": Volgepackt bis unter die Decke, MMU, GBU, 50 Timer, und noch mehr Tralala ... 400 Pins dran und bis man die Treiber dafür geschrieben hat ist die Lebenszeit zu Ende. Läuft nur mit Linux drüber....
Christian J. schrieb: > Ist doch das gleiche mit den A20 "Mikrocontrollern": Volgepackt > bis unter die Decke, MMU, GBU, 50 Timer, und noch mehr Tralala ... 400 > Pins dran und bis man die Treiber dafür geschrieben hat ist die > Lebenszeit zu Ende. Läuft nur mit Linux drüber.... Das sind Mikroprozessoren und keine Mikrocontroller.
So ein großer interner Flash kann sehr sinnvoll für GUIs mit hoher Auflösung sein (Bilder). Die Rechenleistung wird dann auch benötigt damit Animationen flüssig laufen. Oder ein kleiner Webserver... da braucht man auch Platz für die Webseite ansich und eine schnellere CPU kann irgendwelchen dynamischen Kram wie z.B. Diagramme rendern und schneller ausliefern. --> Man kann nie genug Speicher und Rechenleistung haben ;-)
gg schrieb: > So ein großer interner Flash kann sehr sinnvoll für GUIs mit hoher > Auflösung sein (Bilder). > Die Rechenleistung wird dann auch benötigt damit Animationen flüssig > laufen. > Oder ein kleiner Webserver... da braucht man auch Platz für die Webseite > ansich und eine schnellere CPU kann irgendwelchen dynamischen Kram wie > z.B. Diagramme rendern und schneller ausliefern. > > --> Man kann nie genug Speicher und Rechenleistung haben ;-) Das mag schon sein, aber andere sind damit überfordert. Also nimm gefällist Rücksicht. ;)
adenin schrieb: >> --> Man kann nie genug Speicher und Rechenleistung haben ;-) > > Das mag schon sein, aber andere sind damit überfordert. > Also nimm gefällist Rücksicht. ;) OK OK gut, ich sag dann Atmel/ST/Freescale morgen bescheid, dass sie die neuen Produkte doch besser wieder einstampfen da die Kunden sonst panisch im Kreis laufen werden und nicht wissen was sie damit tun sollen ;-)
adenin schrieb: > Das mag schon sein, aber andere sind damit überfordert. > Also nimm gefällist Rücksicht. ;) Denk dir einfach, dass in den Denkfabriken von ARM, da wo die blassen und pickligen Spi.. ähm Designer sitzen den ganzen Tag darüber nachgedacht wird, was das Volk noch so alles braucht. Entwicklung um jeden Preis, hauptsache was Neues. Da man die Taktrate nicht mehr steigern kann wird in die Breite gebaut, mehr Kerne, mehr Peripherie, mehr Register, mehr ROM und RAM.... und alles schön erklärt auf 2500 Seiten Handbuch im Taschenbuchformat. Gaga....
Manfred Dillberger schrieb: > Habe gerade diesen Artikel über die neuen Cortex M7 gefunden: > > http://www.elektroniknet.de/halbleiter/mikrocontroller/artikel/115300/ > > 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. > > 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? So viel anders als M3/4 ist M7 nicht. Und die Devices werden die Hersteller auch nicht neu erfunden haben. Also wird man die ganzen RTOSe wie Ethernut, Freertos etc recht einfach anpassen können. Und wenn das ganze nicht mehr kostet, warum nicht nutzen oder zumindestens Platz fuer Erweiterungen haben? Ich will von STM32 auf keinen Fall mehr zu AVR zurueck.
Ist zwar kein M7, aber wir setzen bei unserer Applikation auf die Infineons. Da hat alleine die GPTA (Timer Array) größer 300 Seiten! Ein echtes Monster.
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.
Wenn man mir in den 80er Jahren erzählt hätte, dass ein durchschnittlicher Laptop bald 4GB Ram und zwei CPU's mit 2GHz haben würde, hätte ich ihn in die Klapsmühle geschickt. Damals konnte ich mir auch nicht vorstellen, an Programmen mit mehreren hundert tausend Zeilen Code zu arbeiten. Heute schauen wir Vide-On-Demand, schicken Fotos mit wenigen Handgriffen in die ganze Welt, lassen uns von "In 50 Metern rechts abbiegen, dann: sie haben ihr Ziel erreicht" leiten und spielen Videospiele mit Bildqualitäten, die es damals nichtmal im Kino gab. Heute bastle ich mit WLAN-Modulen - in den 80ern war man schon fast ein Held, wenn man wusste, wozu ein flankengesteuertes J/K Flipflop gut ist. Früher sammelten wir kistenweise Fotos, heute passt die hundertfache Menge in besserer Qualität auf einen winzigen Chip, den wir mit uns herum tragen. Dieser technische Fortschritt ist nicht nur schlecht.
Stefan Us schrieb: > Früher sammelten wir kistenweise Fotos, heute passt die hundertfache > Menge in besserer Qualität auf einen winzigen Chip, den wir mit uns > herum tragen. 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 :-)
A. K. schrieb: > Was wäre denn dein Wunschcontroller? > Eine 10GHz Z80 mit 6850 als UART? ;-) Ich halte es daher mit meinem ehemaligen Motorrad, einer 1 Zyl Suzuki Savage.. man muss jeden Takt hören können :-) Überlege schon mein Testament in einem EPROM beim Notar zu hinterlegen, wärer ja stilecht als Elektroniker :-)
> Und dann kommt der böse EMP Impuls ... oder das Handy fällt dir in den Dreck Oder ein Brand fackelt die Wohnung samt Fotokisten ab, während ich mein Handy retten konnte (ohne mein Handy kann ich mich ja gleich aufhängen :-) > Ich halte es daher mit ... einer 1 Zyl Suzuki Savage.. Oh, dann passen wir ja gut zusammen. Ich hab auch eine. > Überlege schon mein Testament in einem EPROM beim Notar zu hinterlegen Irgendwo im Internet gab's ein Foto von einem Grabmal, wo in einer Urne ein USB Stick lag, mit Informationen über den verstorbenen.
Wenn dus nicht brauchst, dann benutz es nicht und kauf kleinere Controller. Die Leute dies brauchen werdens schon merken ;)
Christian J. schrieb: > der Plattencrash und wie bei mir > veschwinden 10 Jahre Softwaresammlung + 2000 Fotos im Nirvana. 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 :-))
ttl schrieb: > das Thema EMP-Impuls ist doch schon seit Jahrzehnten erledigt Wie das? Hat sich die Physik verändert?
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 Dimplomarbeit, zig Fotos von Sauforgien aus dem Studiwohnheim, zig alte Softwareprojekte und jede Menge DOS und Windows 95 Programme die kein Mensch mehr braucht. Ja, ich habe gelernt ohne diese Daten zu leben. Der Entzug war schwer aber der Arzt sagte mir, dass ich drüber wegkommen werde.
Wo soll der EMP herkommen mit ausreichender Feldstärke? Falls die Explosion so nah ist das die Feldstärke ausreicht um Schaden anzurichten ist dir der USB-Stick in der Hosentasche eh egal.
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?
Cyblord ---- schrieb: > Die Frage ist, will man ohne? Ohne mein Smartphone gehe ich nirgendwohin! Fest integrierter Bbestandteil meines Körpers!
Stefan Us schrieb: > Irgendwo im Internet gab's ein Foto von einem Grabmal, wo in einer Urne > ein USB Stick lag, mit Informationen über den verstorbenen http://vonheddernheim.de/wordpress2/sprechende-urne/
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. ;-)
A. K. schrieb: > Christian J. schrieb: > Gaga.... > > Was wäre denn dein Wunschcontroller? > Eine 10GHz Z80 mit 6850 als UART? ;-) Was ist denn ein drei Fußballfelder großer Z80 mit mindestend ebenso großer externer Peripherie für ein Vergleichsobjekt? Nimm nen winzigen AVR- alles drin, alles dran, und die Leistung langt auch fast überallhin...
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. ;-)
:
Bearbeitet durch User
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. ;)
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 ;-)
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.
:
Bearbeitet durch User
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." ;-)
:
Bearbeitet durch User
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.
:
Bearbeitet durch Moderator
Chris D. schrieb: > Bei einem grafischen Display und angenommenen 800x480 bei 24 Bit > Farbtiefe ist etwas Leistung schons ehr angenehm. Und man möchte auch > nicht immer einen extra Grafikcontroller anbinden. Wenn ich mich nicht verlesen habe, hat der ATMEL SAMx7 garkeinen Grafikcontroller. Und der STM32F429 verschwendet ganz schön viele Beinchen dafür + ext. RAM, es sei denn, man schafft es, Bilder mit 800x480 bei 24 Bit Farbe im internen RAM unterzubringen ;-)
Chris D. schrieb: > es gibt > da richtig viel zu entdecken :-) Es gibt da richtig viel zu konfigurieren ;-) Umstieg ohne Not = gaga. Ganz unabhängig von der geistigen Leistungsfähigkeit des Subjekts.
Detlef Kunz schrieb: > Wenn man erst Umsteigt, wenn man in Not ist ==> gaga :) Die geistige Leistung des Subjekts sollte natürlich schon in der Lage sein, die Not bereits in der Ferne zu entdecken ;-)
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.
:
Bearbeitet durch Moderator
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.
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.
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.
:
Bearbeitet durch Moderator
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.
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
Manfred Dillberger schrieb: > Cortex M7 zu überzüchtet Keineswegs, der Cortex M7 ist explizit als uC-Alternative zum Cortex R4 Prozessor für Automotive-Anwendungen gedacht (insbesondere Lockstep). Der R4 hatte als ARM Prozessor immer das Problem, dass das Programmiermodell für die uC-Programmierer wohl zu ungewohnt war.
Moby schrieb: > Das lässt sich doch auch locker 8-bittig realisieren. Netzwerkanbindung > via 3€ China ESP8266. Kann der SSL?
Manfred Dillberger schrieb: > Habe gerade diesen Artikel über die neuen Cortex M7 gefunden: > > http://www.elektroniknet.de/halbleiter/mikrocontroller/artikel/115300/ > > 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. Leider haben die Dinger immer noch zu wenig RAM. DRAM und Logik auf einem Die scheint wohl immer noch problematisch zu sein.
Södü schrieb: > Moby schrieb: > >> Das lässt sich doch auch locker 8-bittig realisieren. Netzwerkanbindung >> via 3€ China ESP8266. > > Kann der SSL? Sicher erfüllt so ein Modul nicht jeden Wunsch (SSL ist meines Wissens nicht dabei),aber mal auf jeden Fall die verlangte Funktionalität. An der Auswahl anderer Netzwerkmodule besteht ja nun auch kein Mangel.
> 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. Dass das alles im Grunde problemlos machbar ist, daran besteht kein Zweifel. Die Frage ist nur ob ich so was will. Ein Schalter am Gerät ist mir jetzt lieber als eine schwachsinnige App, wo dann das Einschalt Signal über 10 Ecken zum Gerät kommt. Und wer was von Software versteht, der weiss, dass es keine fehlerfreie gibt. Und die Störungsempfindlichkeit wird dadurch auch nicht gerade verbessert. Ich hab halt lieber ein Gerät dass unter allen Bedingungen und Umständen funktioniert bzw. die Fehlersuche überblickbar ist, als eine Blackbox mit unnötigem Firlefanz. Grüsse
Moby schrieb: > Sicher erfüllt so ein Modul nicht jeden Wunsch (SSL ist meines Wissens > nicht dabei),aber mal auf jeden Fall die verlangte Funktionalität. An > der Auswahl anderer Netzwerkmodule besteht ja nun auch kein Mangel. Ohne vernüftige Krypto sind Geräte die IP machen und Physik steuern nicht zu gebrauchen, wenn nicht sogar grob fahrlässig.
Södü schrieb: > Ohne vernüftige Krypto sind Geräte die IP machen und Physik steuern > nicht zu gebrauchen, wenn nicht sogar grob fahrlässig. Na nun mach mal nen Punkt- bzw. einen Unterschied zwischen gewerblich und Hobby. Ist schon klar daß gewerblich andere Maßstäbe gelten (wenngleich SSL allein auch keine absoluten Sicherheitsgarantien bietet). Privat ist mir Verschlüsselung via SSL absolut wurscht. Da wird die "Sicherheit" bei der Ablesung von Herd- und Waschmaschinenstatus in einer Selbstbau-Haussteuerung durch andere Faktoren viel besser gewährleistet ;-)
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.
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?
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.
Moby schrieb: > Na nun mach mal nen Punkt- bzw. einen Unterschied zwischen gewerblich > und Hobby. Ist schon klar daß gewerblich andere Maßstäbe gelten > (wenngleich SSL allein auch keine absoluten Sicherheitsgarantien > bietet). Privat ist mir Verschlüsselung via SSL absolut wurscht. Da wird > die "Sicherheit" bei der Ablesung von Herd- und Waschmaschinenstatus in > einer Selbstbau-Haussteuerung durch andere Faktoren viel besser > gewährleistet ;-) Versicherungen könnten sich Aktoren die was im Haus steuern sehr dafür interessieren.
Lothar schrieb: > anfred Dillberger schrieb: >> Cortex M7 zu überzüchtet > > Keineswegs, der Cortex M7 ist explizit als uC-Alternative zum Cortex R4 > Prozessor für Automotive-Anwendungen gedacht (insbesondere Lockstep). > Der R4 hatte als ARM Prozessor immer das Problem, dass das > Programmiermodell für die uC-Programmierer wohl zu ungewohnt war. Manfred Dillberger schrieb: > Habe gerade diesen Artikel über die neuen Cortex M7 gefunden: > > http://www.elektroniknet.de/halbleiter/mikrocontroller/artikel/115300/ > > 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. Wer den Artikel sorgfältig zwischen den Zeilen liest stellt fest: STM hat zwar angekündigt aber der normale Entwickleer im Kleinbetrieb ohne NDA und 1Mpcs/a wird den irgendwann dieses Jahr mit Datenblättern und evtl in Silizium sehen. Wenn Atmel jetzt ankündigt kommt der IMHO frühestens zu Weihnachten 2015 auf den Tisch - genau gesagt late H2'2015. Wenn freesacle jetzt "zuspielt" halten Sie sich bedeckt oder haben noch zu wenig, dann wird das IMHO 2016 mit Silizium. Ist alles Sepkulation mit den Daten genausoviel wir der Artikel über die Verfügbarkeit sagt. Bis dahin kann STM seinen M7 auch auf 40 oder 60nm - oder was die halt haben oder mit welcher Foundry zusammenarbeiten - shrinken. Dann kann der auch um die 300...400MHz. Dann ist auch mehr Flash und SRAM drinnen. Die Frage "warum 400MHz" ist mit dem Artikel auch angerissen. Es scheint (!) noch Bedarf zwischen den Cortex A und den M zu existieren. Und wenn man (Industrie) bedenkt dass sich die Herstellungskosten (jetzt kommt bei uns evtl auch noch Deflation hinzu) per se nach unten entwickeln ist eine gute Skalierbarkeit immer gefragt. Da ist ein Ausbau der Prozessorlinie nach oben hin immer gut dann kann der Kunde versuchen bei der nächsten Generation der Cost-Down Entwicklung auf Devices setzen die sich nach unten besser skalieren lassen und dann mit der M7 in Applikationen einsteigen, die Multimedia oder anderes auf M7 macht und das bei Bedarf abstrippen auf M4 (der wird sich auch noch von der Performance nach oben entwickeln und vom Preis nach unten). Applikationen gibt es dafür wie Sand am Meer, wichtig ist Ethernetanbidnung (Schimpfwort IoT). Damit ist auch die Frage nach dem Flash beantwortet: davon hat man nie genug. Die Frage des Flashes und der Geschwindigkeit ist aber auf unangenehme weise miteinander verknüpft: je schneller der Prozessor desto mehr muss ich aus dem Flash parallel in die Pipeline stellen damit der Prozessor tatsächlich auch die 400MHz ausführen kann. Beim Branch stallt der dann ohnehin mit hoher Wahrscheinlichkeit. Es sei denn ich arbeite an den Caches die der M4 schon hat hinsichtlich Größe und an der Pipeline (zwiete Pipeline, Brach prediction, ..). In diesem Zuge werden dann aber RAM_Interfaces (SD-RAM, DDR-Ram) wichtiger da die die Prozessorgeschwindigkeit besser bedienen können und auf einen Stall können die schneller reagieren. Das geht dann stark in die A Richtung. Gut wo werden wir 2016 rauskommen: der M7 - wenn er denn real verfügbar ist - hat irgendwo zwischen 300...400MHz, die Devices sind - wie auch die bisherigen - immer noch nicht "bug-free" es wird errata und weitere Steppings geben. Freescale, STM, Atmel und vielleicht noch andere werden M7 mit irgendwo 1...8MB Flash anbieten, Varianten mit ...32MB wird es irgendwann zwischen 2016 und 2017 geben (wenn es jemand zahlen will und benötigt). Applikationen wird man finden, die Kunden (Industrie) werden Möglichkeiten finden den Endkunden diese schmackhaft zu machen und die Kunden werden die Applikationen lieben da sie das Leben in bunten Farben und Pseudokommunikation (Ichkenndichnichtaberhabevondireinfoto-book, Ichtelefoniernichtaberschreibedirirgendwas-App, ...) und ClickiFoti schöner, heiler und weiter weg von der Arbeit machen. Aber das ist auch nur eine Interpretation dessen was da steht, der das von jemanden gehört hat, der ewtas erzählt hat, von jemandem der etwas geplant hat, etwas irgenwo zu realisieren. So ist die Branche eben. rgds
Angehängte Dateien:
-
IMG_20150108_085601.jpg
310 KB
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 ;-)
:
Bearbeitet durch Moderator
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch Moderator
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...
Chris D. schrieb: > 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. Das wird nicht weiter stören. 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. 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. 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. ;-)
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 :-)
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.