Hallo, mein Attiny Vorrat ist gerade zur Neige gegangen. Ich bin am überlegen ob ich neu bestellen soll oder STM32f0xx ordern soll. Welche Käfer nehmt ihr für kleine Projekte (z.B. kleine IR-Fernbedienung mit einem Taster)? Ich suche auch speziell einen für Batterie Anwendungen.
Wenn deine Anwendungen in Tinys passen, warum das Pferd im Rennen tauschen? Oder anders formuliert: Wenn es dem Esel zu gut geht, dann geht er aufs Eis.
Falls du dich schon tief in die AVR Welt eingearbeitet hast, ist ein Wechsel auf eine andere Architektur nicht ratsam. Für ein Sensorboard haben wir einen ATtiny85 im Einsatz, der nun schon drei Jahre mit einer 3V Knopfzelle arbetet. Softwaremässig lässt sich bez. Batteriebetrieb einiges machen.
Gerne den ATTiny85 der hat jede menge Platz wenn man wie ich nicht gerade sparsamen Code schreibt. Den ATTiny4313 wenn es mal ein paar Pins mehr seien dürfen. Ganz oben auf der Wunschliste bei der nächsten Bestellung steht der ATTiny10 (2,9 mm x 1,6 mm, 6 Pins ).
Wenn das Projekt klein genug ist (z.B. ein bestimmtes IR-Telegramm zu senden, wenn man auf den Taster drückt, so habe ich die Anwendung im Eingangspost verstanden), nehme ich auch gern mal eien PIC10F_irgendwas im SOT-23. Bevor man im STM32xxx die ganzen Clocks konfiguriert und die CMSIS-Structs für die doch recht komplexen Peripherien gefüllt hat, hat man das Programm für den PIC schon halb fertig...
Ordere STM32f0xx. Dann hast du fürs nächste Mal eine Unklarheit beseitigt.
Peter F. schrieb: > Ich bin am > überlegen ob ich neu bestellen soll oder STM32f0xx ordern soll. Warum nicht beides ordern? Es ist übrigens nicht so, das es Cortex M0 nicht in 8-Pin Gehäuse gäbe: http://www.nxp.com/products/microcontrollers/core/cortex_m0plus_m0/LPC810M021FN8.html Aber das eine schliesst ja das andere nicht aus. Der LPC810 hat allerdings nur 4k Flash.
Hallo, ich habe meine ATTiny10 von https://guloshop.de/ erhalten. LunaAVR kann nun auch inoffiziell, da noch in der Testphase, auch Code für den ATTiny10 erzeugen. Holger L. schrieb: > ATTiny10
>Aber das eine schliesst ja das andere nicht aus. Der LPC810 hat >allerdings nur 4k Flash. Den LPC810 hatte ich schon verwendet. Er hat zwar mehr Rechenleistung, aber die Attinys haben AD-Wandler. Beim LPC810 kann man nur einen SAR ADC mit 5 Bit Auflösung in Software mit Hilfe des Analog-Comparators realisieren.
Oertel schrieb: > Ordere STM32f0xx Die kosten mit 16K Flash und 48 MHz schon 1.30 Zum selben Preis gibt es 8051 mit 64K Flash 72 MHz 14-bit ADC und 4x DAC: EFM8LB12 auch als SSOP Matthias S. schrieb: > Es ist übrigens nicht so, das es Cortex M0 nicht in 8-Pin Gehäuse gäbe LPC812 mit 16K Flash gibt es in SOIC
> aber die Attinys haben AD-Wandler Leider aber keine versorgungsspannungsunabhängige Referenz. Daher musste ich mal ein Projekt von Tiny10 auf PIC10F320 wechseln.
> LunaAVR kann nun auch inoffiziell, da noch in der Testphase, auch Code > für den ATTiny10 erzeugen. AVR-GCC macht das auch offiziell!
chris_ schrieb: > Den LPC810 hatte ich schon verwendet. Er hat zwar mehr Rechenleistung, > aber die Attinys haben AD-Wandler. Hier gibt es ja inzwischen den LPC824 mit 12-bit ADC
Carl D. schrieb: > AVR-GCC macht das auch offiziell! Ja ja und bis es so weit war, hat jemand den Code getestet - das nennt man Compilerbau !
Holger L. schrieb: > Ganz oben auf der Wunschliste bei der nächsten Bestellung steht der > ATTiny10 (2,9 mm x 1,6 mm, 6 Pins ). Und warum? Schwerer zu bekommen, iirc anderes Programmierinterface, teurer als der 13er, weniger Beine, weniger Flash, weniger.... Also alle Nachteile vereint. Atiny13 gibts überall sackweise für Centbeträge nachgeschmissen. Ok er ist kleiner von den Amessungen aber die paar Millimeter,...
Eine schöne Sache ist eben der AD Wandler mit Differenzeingang, den man mit den Tiny25/45/85 hat. Dafür lasse ich den Tiny13 dann auslaufen und verbau nur noch die Restbestände. neuer PIC Freund schrieb im Beitrag #4377288: > Leider aber keine versorgungsspannungsunabhängige Referenz. Naja, wenn einem beim Tiny25 die 1,1V intern reichen, dann hat er das schon. Nur ist es nicht möglich, die nochmal extern abzublocken - für ganz anspruchsvolle Messungen müsste man dann Sleep einbauen.
Moin, Die STM32 sind schon wirklich feine Teile. Solange dich an den AVRs aber nichts stört und du nichts vermisst, dann rate ich dir von einer Umstellung bei so kleinen Projekten aber dennoch generell ab. Ich bin schon vor geraumer Zeit weg von AVRs und nutze für kleine Projekte gerne STM8 Controller. Gerade der STM8S003 ist wahnsinnig günstig, klein (3x3mm bei "handlötbarem" QFN) und vielseitig! schönen Gruß, Alex
abc@def.de schrieb: > Und warum? [...] Eigentlich nur wegen der geringen Größe, fand das interessant mache aber auch selten was in SMD. Der Flash ist übrigens mit 1 K Byte genau wie bei dem ATTiny13 nur der SRAM ist halb so groß. Dafür hat er einen 16 Bit Timer, und mit 0.1 µA is er doch recht sparsam. Die TPI Programmierung habe ich noch nie ausprobiert, mit meinem ALL-AVR Programmer kann der Resetpin im Gegensatz zu SPI, gefahrlos entfernt werden. Außerdem kann man bei 60 Cent nicht viel verkehrt machen.
arduino mini 328p wozu kleiner wenn die Quelle auch eine CR2032 schon größer ist?
Es kommt doch ganz darauf an um was für ein Projekt es sich handelt, es gibt schließlich nicht nur CR2032 sondern auch LR44 und viele andere Typen.
Thomas E. schrieb: > Wenn das Projekt klein genug ist (z.B. ein bestimmtes IR-Telegramm > zu > senden, wenn man auf den Taster drückt, so habe ich die Anwendung im > Eingangspost verstanden), nehme ich auch gern mal eien PIC10F_irgendwas > im SOT-23. Bevor man im STM32xxx die ganzen Clocks konfiguriert und die > CMSIS-Structs für die doch recht komplexen Peripherien gefüllt hat, hat > man das Programm für den PIC schon halb fertig... Das macht doch die HAL für dich, zumindest zum größten Teil. Ähnlich sieht es bei NXP aus, da gibt es auch Libraries für alle grundlegenden Kern- und Peripheriefunktionen.
greg schrieb: > Das macht doch die HAL für dich, zumindest zum größten Teil. Ähnlich > sieht es bei NXP aus, da gibt es auch Libraries für alle grundlegenden > Kern- und Peripheriefunktionen. Das Hauptargument für LPC gegenüber STM32 oder SAM war eigentlich, dass deren Peripherie deutlich einfacher gestrickt ist und es noch relativ problemlos ohne HAL geht. Bei STM32 frisst die SPL schon einen Teil der Leistung und bei den kleinen SAM frisst das ASF fast das ganze RAM
Warum sollte man sich das antun? Selbst z.B. auf einem LPC810 kann man einfach einige der fertigen Treiberkomponenten nehmen, ohne gleich den sehr knappen Flash zu sprengen. printf ist da viel schlimmer, sogar als micro-Variante mit stark reduzierten Features. :)
Lothar schrieb: > greg schrieb: >> Das macht doch die HAL für dich, zumindest zum größten Teil. Ähnlich >> sieht es bei NXP aus, da gibt es auch Libraries für alle grundlegenden >> Kern- und Peripheriefunktionen. > > Das Hauptargument für LPC gegenüber STM32 oder SAM war eigentlich, dass > deren Peripherie deutlich einfacher gestrickt ist und es noch relativ > problemlos ohne HAL geht. Ähmm. Nein. Das ist gar kein Argument. Man muß keineswegs ein HAL benutzen. Und schon gar nicht das was ST unter der Bezeichnung SPL verbrochen hat. > Bei STM32 frisst die SPL schon einen Teil der Leistung Und wieder: Nein. Der Grund warum man die SPL (also alles abseits der Definition der Register) nicht benutzen will ist nicht, daß die SPL Leistung frißt. Sondern daß sie unübersichtlich ist und genau gar nichts vereinfacht. Die ersetzt einfach die magischen Namen von Registern und Bits durch - zwar ähnliche, aber subtil veränderte - Namen in C structs. Und fügt einen Haufen Funktionen mit neuen magischen Namen hinzu. Aber: Leistung kostet das nicht. 90% des SPL-spezifischen Quellcodes kriegt ohnehin nur der Präprozessor zu sehen. Und das der Compiler nachher noch zu generieren hat ist in den meisten Fällen genau das gleiche was er für handgeschriebene Bitschubserei auch erzeugt.
Axel S. schrieb: >> Bei STM32 frisst die SPL schon einen Teil der Leistung > > Und wieder: Nein. Der Grund warum man die SPL (also alles abseits der > Definition der Register) nicht benutzen will ist nicht, daß die SPL > Leistung frißt. Sondern daß sie unübersichtlich ist und genau gar nichts > vereinfacht. Die ersetzt einfach die magischen Namen von Registern und > Bits durch - zwar ähnliche, aber subtil veränderte - Namen in C structs. > Und fügt einen Haufen Funktionen mit neuen magischen Namen hinzu. > Das kann man so pauschal doch gar nicht sagen, jedenfalls nicht bei der neueren STM32 HAL. (Die SPL sollte man doch hoffentlich nicht mehr verwenden.) Die HAL macht den Code auf jeden Fall deutlich lesbarer und erlaubt eine gewisse Portabilität (innerhalb der STM32-Welt). Wenn bspw. der UART mit 115200 Baud laufen soll, setz ich bei der HAL das Feld "BaudRate" auf jenen Wert und die HAL kümmert sich um den Rest. Sonst müsste ich selbst erst einmal schauen mit welchem Takt die UART läuft und die passende Werte für die Baudratenregister errechnen. Das ist eine Abstraktion, die Sinn macht. Anderes Beispiel, bei I2C implementiert die HAL praktischerweise den Ablauf einer Transaktion zum Lesen und Schreiben von Registern von Slaves, das macht man dann mit nur einem Funktionsaufruf. Und letztendlich muss man die Konstanten und Felder die bei der HAL benutzt werden zwar nachschlagen, aber so "magisch" wie irgendwelche Registerbits ist der Kram nicht mehr. > Aber: Leistung kostet das nicht. 90% des SPL-spezifischen Quellcodes > kriegt ohnehin nur der Präprozessor zu sehen. Und das der Compiler > nachher noch zu generieren hat ist in den meisten Fällen genau das > gleiche was er für handgeschriebene Bitschubserei auch erzeugt. Was soll "kostet Leistung" überhaupt heißen? Den größten Nutzen und Overhead hat die HAL bei Initialisierung & co, und da kostet es hauptsächlich etwas Flash. Aber wenn man das selbst macht, braucht man auch Flash. Es stimmt schlichtweg aber nicht, dass 90% nur im Präprozessor hängen bleibt (oder inline-Funktionen o.ä.), da ist schon ein gewisser Overhead da. Mit Link-Time-Optimization bekommt man das aber gut in den Griff. Ansonsten, wenn die Abstraktion tatsächlich so wenig Overhead hat, dann ist das doch sehr gut?!
Für Projekte mit einem achtbeinigen Käfer ist normalerweise alles jenseits AVR overkill hoch zehn. Nachdem du dich dazu noch so gut damit auskennst wäre es sinnlos zu wechseln. Einzig wenn du die Herausforderung suchst wäre das was....
Die neue HAL von ST ist leider grauenvoll dokumentiert. Und die Beispiele teilweise richtig schlecht. Die USB-Examples sind alles andere als sauber geschrieben. Von dem USB-Stack ganz zu schweigen. Der ist für Composite Devices gänzlich unbrauchbar. Ich nutze trotzdem die STM32, aber nur wenn ich sie auch brauche. Bei einfacheren Sachen finde ich einen Avr deutlich effektiver. Mit weniger komplexer Peripherie kommt man eben schneller zum Ziel, sofern diese ausreicht. Auch der Avr-Core ist weniger komlex als ein ARM-Core. Das alles spart Entwicklungszeit. Weniger Komplexität -> geringere Fehleranfälligkeit. Den ganzen Bibliothekskrempel von ST kann ich aber wirklich nicht hochloben. Dafür hab ich schon zu oft darüber geflucht. Es gibt genug undokumentierte Funktionen. Und teilweise ist die Cube-Lib einfach nur dämlich. Ein einfacher interruptgesteuerter UART mit FIFO ist da schon ein Krampf.
avr schrieb: > Bei > einfacheren Sachen finde ich einen Avr deutlich effektiver. Mit weniger > komplexer Peripherie kommt man eben schneller zum Ziel, sofern diese > ausreicht. Auch der Avr-Core ist weniger komlex als ein ARM-Core. Das > alles spart Entwicklungszeit. Weniger Komplexität -> geringere > Fehleranfälligkeit. Genau so ist es. Ich empfehle auch, beim AVR zu bleiben und sich nicht von Modetrends, 'Veraltet'-Geläster und zwar objektiv vorhandener, aber für die konkrete App sehr oft unnötiger ARM Leistungsfähigkeit blenden zu lassen. > Den ganzen Bibliothekskrempel von ST kann ich aber wirklich nicht > hochloben. Dafür hab ich schon zu oft darüber geflucht. Es gibt genug > undokumentierte Funktionen. Und teilweise ist die Cube-Lib einfach nur > dämlich. Ein einfacher interruptgesteuerter UART mit FIFO ist da schon > ein Krampf. Deshalb gibts in meinen Augen nichts Effektiveres, als die MC Tatsachen ohne Umwege und ganz nach Wunsch direkt anzusprechen. Freilich erfordert das genaue Hardware-Kenntnis. Die ist aber beim AVR noch vertretbar einzuholen.
avr schrieb: > Auch der Avr-Core ist weniger komlex als ein ARM-Core Der ARM-Core selbst hat deutlich weniger und orthogonale Assembler-Befehle als der AVR-Core und ist damit eindeutig weniger komplex. Das Problem ist die Peripherie mancher ARM-Hersteller, das gilt aber grade nicht für die LPC Schaut mal im direkten Vergleich einen größeren AVR atmega2560 und einen LPC1168 an, beim AVR ist dieselbe Peripherie deutlich komplexer realisiert als beim LPC (schon weil der I/O-Space nicht reicht und wegen der 8-bit Register für 10-bit ADC usw)
Lothar schrieb: > Der ARM-Core selbst hat deutlich weniger und orthogonale > Assembler-Befehle als der AVR-Core und ist damit eindeutig weniger > komplex. Komplexität allein an der Anzahl der Asm Instruktionen festzumachen ist schon etwas verwegen. Unbedingt empfehlenswert ist dazu in jedem Fall ein vergleichender Blick ins deutlich kürzere Atmega2560 bzw. größere LPC11xx User Manual- dann fällt sehr schnell ins Auge, was da wohl insgesamt komplexer ist. Schon die LPC Memory-Map für sich ist sehr aufschlußreich... Davon abgesehen war ja von Attiny-Ersatz die Rede.
Lothar schrieb: > Der ARM-Core selbst hat deutlich weniger und orthogonale > Assembler-Befehle als der AVR-Core und ist damit eindeutig weniger > komplex. Darum ging es mir nicht. Ich programmiere den ARM nicht in Assembler. Ich hatte beispielsweise auf Avrs noch keine ekelhaften Hardfaults gehabt, die Stunden zum Debuggen brauchen (um am Ende ein fehlerhaften Startupcode zu identifizieren...). Beim Avr ist vieles einfacher gestrickt und daher weniger fehleranfällig. Das soll keine Wertung sein, welcher Controller besser ist. Ich sage nur, dass ich für einfachere Projekte Avrs bevorzuge. Rein gefühlsmäßig geht einfach weniger schief. > Das Problem ist die Peripherie mancher ARM-Hersteller, das gilt aber > grade nicht für die LPC > > Schaut mal im direkten Vergleich einen größeren AVR atmega2560 und einen > LPC1168 an, beim AVR ist dieselbe Peripherie deutlich komplexer > realisiert als beim LPC (schon weil der I/O-Space nicht reicht und wegen > der 8-bit Register für 10-bit ADC usw) Schau dir doch mal einen Attiny4 und einen LPC43xx an. Ja, so ähnlich war dein Vergleich. BTW: Ich habe noch nie einen Atmega2560 eingesetzt und werde es auch wohl nie machen. Ich nutze zu 99% entweder Attinys oder irgendwelche ARM-µCs. Und nochmal ich programmiere wenn überhaupt nur in Ausnahmefällen Assembler. In allen anderen Fällen sind mir 16bit Register auf 8bit Controllern egal. Das macht der Compiler. Genauso wie der zu kleine IO-Space.
greg schrieb: > Axel S. schrieb: >>> Bei STM32 frisst die SPL schon einen Teil der Leistung >> >> Und wieder: Nein. Der Grund warum man die SPL (also alles abseits der >> Definition der Register) nicht benutzen will ist nicht, daß die SPL >> Leistung frißt. Sondern daß sie unübersichtlich ist und genau gar nichts >> vereinfacht. Die ersetzt einfach die magischen Namen von Registern und >> Bits durch - zwar ähnliche, aber subtil veränderte - Namen in C structs. >> Und fügt einen Haufen Funktionen mit neuen magischen Namen hinzu. > > Das kann man so pauschal doch gar nicht sagen, jedenfalls nicht bei der > neueren STM32 HAL. (Die SPL sollte man doch hoffentlich nicht mehr > verwenden.) Wenn du meinen Beitrag gelesen hättest, dann wäre dir aufgefallen daß mein Rant gar nicht pauschal war, sondern sich explizit auf die SPL bezogen hat. > Die HAL macht den Code auf jeden Fall deutlich lesbarer und > erlaubt eine gewisse Portabilität (innerhalb der STM32-Welt). Wenn bspw. > der UART mit 115200 Baud laufen soll, setz ich bei der HAL das Feld > "BaudRate" auf jenen Wert und die HAL kümmert sich um den Rest. Sonst > müsste ich selbst erst einmal schauen mit welchem Takt die UART läuft > und die passende Werte für die Baudratenregister errechnen. Ja. Schrecklich. Raketentechnik. Die Mondlandung war geradezu ein Klacks im Vergleich zu dieser Herausforderung. Wie kann jemand mit diesem Mindset überhaupt auf die Idee kommen, Software schreiben zu wollen? >> Aber: Leistung kostet das nicht. > Was soll "kostet Leistung" überhaupt heißen? Das mußt du schon Lothar(Gast) fragen. Er hat schließlich diese steile These aufgestellt. Aber vermutlich meint er damit das gleiche wie der Rest der Welt auch: höherer Bedarf an Rechenzeit und (bzw. wegen) mehr Code für die gleiche Funktionalität. > Den größten Nutzen und Overhead hat die HAL bei Initialisierung & co, Du hast das Konzept einer HAL verstanden? Eine HAL die nicht alle Aspekte der Hardware abdeckt, ist keine. Es geht keineswegs nur um die Initialisierung, sondern auch um die Benutzung der Hardware. Also um mal ein Beispiel zu bringen: nicht nur um eine Funktion zur Initialisierung der UART, sondern auch Funktionen zum Senden und Empfangen. > und da kostet es > hauptsächlich etwas Flash. Aber wenn man das selbst macht, braucht man > auch Flash. Ja, das schrieb ich bereits. Der Overhead durch die Benutzung der HAL ist marginal. > Ansonsten, wenn die Abstraktion tatsächlich so > wenig Overhead hat, dann ist das doch sehr gut?! Nur wenig Overhead zu erzeugen, reicht nicht für ein "sehr gut". Genauso wie du für die Mathearbeit keine 1 bekommst, nur weil du deinen Namen und das Datum fehlerfrei hingeschrieben hast. Und apropos SPL vs. "neue HAL". Damit meinst du wohl das Cube Zeug. Habe gerade mal kurz reingeschaut und mich mit Grauen wieder abgewendet. Allein die Größe ist schon ein schlechter Witz: die STM32F0 Cube HAL ist ein 98MB (!) großes Zipfile. Fast 100MB für einen Controller der nicht mal 100KB Flash hat. Dann habe ich interessehalber mal in die USB-Lib geschaut. Da stimmen stellenweise noch nicht mal die Funktionsnamen in den Kommentaren mit den echten Funktionsnamen überein. Die Formatierung ist grauenhaft. Und natürlich haben sie den Bullshit mit den struct's mit magischen Membernamen genauso durchgezogen wie in der SPL. Und so etwas soll ich als Basis einer Applikation verwenden? Da kann ich auch gleich ein Haus auf eine Treibsandgrube bauen...
Hallo, also ich habe so als Standard CPU für kleine Projekte den ATxmega8E5(16E5,32E5), er ist schnell und einfach und hat auch einen 12 Bit DAC drauf. Hingegen haben die meisten CM0 nur 10 Bit DAC. Auch der ADC hat PGA und differentziellen ADC mit 12 Bit. Die meisten CMO Controller sind bereits schon wieder viel zu komplex, aleine nur die Initialisierung. Und übrigens er hat noch ein brauchbares (Lötbares) Gehäuse. Mit 32 Pins und 0.8 Pitch (TQFP32). Gruß Sascha
avr schrieb: > Ich hatte beispielsweise auf Avrs noch keine ekelhaften Hardfaults > gehabt, die Stunden zum Debuggen brauchen Kannst Du mal ein Beispiel geben? Ich hatte noch nie einen Hardfault. Allerdings einmal in 5 Jahren einen Memoryfault bei einem großen ARM, weil ich vergessen hatte, dass zwar ingesamt genügend RAM da war, aber nicht am Stück. Aber was muss man da debuggen? Der Memoryfault Handler schreibt die fehlerhafte Adresse über UART raus und dann weiss man es. Andererseits habe ich grade einen 8051 EFM8 den musste ich wirklich debuggen :-) Um hier auch nur den UART zum laufen zu bekommen, muss man haufenweise Register setzen (Power Management, Crossbar/PinMUX, CLK Divider, Enables)
Lothar schrieb: > Kannst Du mal ein Beispiel geben? Mit Hardfaults meinte ich eigenlich allgemein Faults. Erst letztens als ich mal doch wieder Coocox genutzt habe. Der Startupcode dort setzt den Stackpointer nicht an das Ende des Rams. Doch bis ich auf die Idee kam, dass es irgendwo so dämlichen Startupcode gibt ist eine Menge Zeit vergangen. Dazu muss man wissen, dass ich ausgiebig neuere C++ Features nutze und teilweise auch Exceptions und RTTI auf größeren ARMs (wie M4 bspw.). Wenn da irgendetwas im Startupcode/Linkerskript nicht stimmt, gibt es die seltsamsten Fehler. Bis man auf das eigentliche Problem stößt dauert es ziemlich lange.
Lothar schrieb: > Aber was muss man da debuggen? Der Memoryfault Handler > schreibt die fehlerhafte Adresse über UART raus und dann weiss man es. Wenn man Glück hat, dann gibt es gleich beim Fehler einen Fault. Das Programm kann aber auch noch lange falsch weiterlaufen und alles mögliche machen. So ähnlich war das auch bei mir.
Ein AVR-Tiny4/5/9/10 core dürfte mit einer der kompaktesten überhaupt sein die es gibt. Der passt nämlich zusammen mit 1k Flash, 32 Byte RAM, einem 16-Bit Timer und einem 8-Bit ADC in ein SOT23-6 Gehäuse und das kostet dann unter 1€ (selbst für Bastler). Für die üblichen Aufgaben (LEDs blinken, Abläufe steuern, usw.) reicht aber selbst so einer voll aus.
Sascha schrieb: > also ich habe so als Standard CPU für kleine Projekte den > ATxmega8E5(16E5,32E5), er ist schnell und einfach und hat auch einen 12 > Bit DAC drauf Nur mal zum Vergleich: für den gleichen Preis gibt es 8051 mit 20x 14-bit ADC und 4x 12-bit DAC mit 72 MHz und doppelt so viel Flash / RAM: EFM8LB12F64E-A-QFP32
Ich finde die Cypress PSOC Reihe nicht schlecht, da gibts sehr günstige Boards, (nur 4€) wie z.B. dieses hier: http://de.farnell.com/cypress-semiconductor/cy8ckit-049-42xx/prototype-board-cy8c4245axi-483/dp/2420489 Das tolle ist, die haben DAC, OPV, Logikgatter und noch ein bisschen mehr gleich mit drauf, die man frei verschalten kann. Eine Stufe höher dasselbe mit PSOC 5: http://de.farnell.com/cypress-semiconductor/cy8ckit-059/entw-brd-cy8c5888lti-psoc-5-prototyping/dp/2476010 Für unter 10€ mit 20 Bit ADC, PGA, Digital Filter Block, Boost Converter,...
Moby A. schrieb: > Lothar schrieb: >> Der ARM-Core selbst hat deutlich weniger und orthogonale >> Assembler-Befehle als der AVR-Core und ist damit eindeutig weniger >> komplex. > > Komplexität allein an der Anzahl der Asm Instruktionen festzumachen ist > schon etwas verwegen. Dann reicht es aber aus, nur die Instrukionen zu benutzen die man kennt. Damit bleibt jedes System überschaubar, stimmts Prof. h.c.* AVR? Außerdem, was hat den der M2560 bei Millionen typischer kleiner MS(R) Anwendungen verloren? Ist doch die blanke Resourcenverschwendung. Die IµCRNK (Internationalemikrocontrollerresourcennutzungskommission) wird hoffentlich solches Treiben untersagen. Ziel dürfen höchstens 3% sein. SCNR *humorus causa
Moin, Also was hier so an der ST-Library rumgemeckert wird verstehe ich nicht. Klar, die ist ziemlicher Schrott - aber wer die für mehr als nur Versuche verwendet ist doch eh selbst schuld? Wenn ich neue Peripherie nutzen will nehme ich da irgendein Beispiel und wurste das schnell um. Für Proof-of-Concept eigentlich ideal! Sobald das läuft schaue ich mir deren Code (Kot) an, schnappe mir das Datenblatt und reduziere das Zeugs aus der Library auf ein Minimum, sortiere die Zuweisungen richtig und habe innerhalb kürzester Zeit ein vernünftiges Programm. Da entsteht insbesondere auf STM8 recht performanter und sparsamer Code. STM32 gefällt mir wie gesagt auch ganz gut. Für kleinere Projekte finde ich die aber auch etwas zu umständlich. Die sind super wenn man rechnen muss aber unvorteilhaft für simple Port & Pin geschichten. STM8S verträgt 5V (wimre sogar 6V). STM8L und STM32 sind leider nur für 3,3V gedacht... Laut Datenblatt haben die z.T. 5V-Tolerante Pins - was das jetzt bedeutet weiß ST aber irgendwie selbst nicht so genau... Kaputt ist mir dabei aber noch keiner gegangen ;). Brownout ist bei den 8ern leider etwas sparsam... schönen Gruß, Alex
Axel S. schrieb: >> Die HAL macht den Code auf jeden Fall deutlich lesbarer und >> erlaubt eine gewisse Portabilität (innerhalb der STM32-Welt). Wenn bspw. >> der UART mit 115200 Baud laufen soll, setz ich bei der HAL das Feld >> "BaudRate" auf jenen Wert und die HAL kümmert sich um den Rest. Sonst >> müsste ich selbst erst einmal schauen mit welchem Takt die UART läuft >> und die passende Werte für die Baudratenregister errechnen. > > Ja. Schrecklich. Raketentechnik. Die Mondlandung war geradezu ein Klacks > im Vergleich zu dieser Herausforderung. Wie kann jemand mit diesem > Mindset überhaupt auf die Idee kommen, Software schreiben zu wollen? > Natürlich ist das nicht schwer. Aber wenn einem eine Abstraktion diese unnötige und wiederkehrende Arbeit abnimmt, kann das hilfreich sein. Das bedeutet doch nicht, dass man es nicht zu Fuß könnte. Dein Mindset ist dann wohl, dass man ein Warmduscher und Nichtskönner ist, wenn man nicht jedes Bit mit der Hand anfasst? Oder wie soll ich das verstehen? >> Den größten Nutzen und Overhead hat die HAL bei Initialisierung & co, > > Du hast das Konzept einer HAL verstanden? Eine HAL die nicht alle > Aspekte der Hardware abdeckt, ist keine. Es geht keineswegs nur um die > Initialisierung, sondern auch um die Benutzung der Hardware. Also um mal > ein Beispiel zu bringen: nicht nur um eine Funktion zur Initialisierung > der UART, sondern auch Funktionen zum Senden und Empfangen. > Klar. Aber bei der Initialisierung spielt eine/die HAL ihre Stärken aus, weil das in den meisten Fällen im Gegensatz zur Nutzung der Peripherie (z.B. ein Byte per UART verschicken) eine große Komplexität hat. Das war doch auch genau meine Aussage. > >> Ansonsten, wenn die Abstraktion tatsächlich so >> wenig Overhead hat, dann ist das doch sehr gut?! > > Nur wenig Overhead zu erzeugen, reicht nicht für ein "sehr gut". Genauso > wie du für die Mathearbeit keine 1 bekommst, nur weil du deinen Namen > und das Datum fehlerfrei hingeschrieben hast. > Abstraktionen sind doch nicht gleich sinnlos, nur weil sie etwas Overhead haben. So ein Blödsinn. Es ist eine Kosten/Nutzen-Abwägung. Wenn einen Abstraktion einen Nutzen hat, darf sie in den meisten Fällen auch ruhig etwas kosten. Über die Qualität der HAL mag man sich streiten, aber du beschäftigst dich ja nicht einmal ordentlich damit und urteilst sofort mit "Müll" ab. Wahrscheinlich ist nur dein "Goldener Code" brauchbar, oder wie? (Insbesondere im Kontext des Threads, also "kleine schnelle Projekte" ist die HAL nicht schlecht, da sie einem viel Arbeit abnehmen kann. Auch wenn sie nicht perfekt ist.)
Hallo, @Lothar, cool habe ich noch nicht gesehen, obwohl ich einige Projekte mit Silabs mache. Danke, ist sehr interessant. 72MHz Ups .... nicht schlecht. Gruß Sascha
Alex schrieb: > Also was hier so an der ST-Library rumgemeckert wird verstehe ich nicht. > Klar, die ist ziemlicher Schrott - aber wer die für mehr als nur > Versuche verwendet ist doch eh selbst schuld? Ich finde die Bibliothek nicht so schlecht. Es ist ein guter Versuch Software-Kompatibilität zwischen den Controllern zu schaffen. Aber wo ist die Doku??? Das was es von ST gibt ist definitiv zu wenig. > Wenn ich neue Peripherie nutzen will nehme ich da irgendein Beispiel und > wurste das schnell um. Für Proof-of-Concept eigentlich ideal! Was der Controller kann, kann ich meistens auch im Datenblatt lesen. Außerdem dauert (zumindest bei mir) das Inbetriebnehmen der CubeLib länger als wenn ich die Register direkt beschreibe. Einfach weil diese im Gegensatz zu der Bibliothek richtig dokumentiert sind. Versuch mal mit der CubeLibrary weitere Endpoints zum USB-Stack hinzuzufügen. Zwei wirklich seltsame Funktionen und kein Wort Doku dazu (bei der alten Lib war das übrigens noch verständlich gelöst). > Sobald das läuft schaue ich mir deren Code (Kot) an, schnappe mir das > Datenblatt und reduziere das Zeugs aus der Library auf ein Minimum, > sortiere die Zuweisungen richtig und habe innerhalb kürzester Zeit ein > vernünftiges Programm. Was habe ich denn dann gewonnen? Wenn es schon mit der CubeLib läuft, dann ist es nur Zeitverschwendung das umzuschreiben. Denn die Plattformkompatibilität unter stm32 Controllern, welche sie bietet hat dein Code sicherlich nicht. > Da entsteht insbesondere auf STM8 recht performanter und sparsamer Code. Mit LTO hat man sowieso (fast) keinen Overhead.
avr schrieb: > Ich finde die Bibliothek nicht so schlecht. Es ist ein guter Versuch > Software-Kompatibilität zwischen den Controllern zu schaffen. Das nenne ich mal einen Witz. Wer in vergangenen Tagen die alte STM-Lib benutzt hat, wird wohl kein ernsthaftes Projekt auf die neue Hal-Schiene umstellen können. Wenn das ganze dann aber auf einen neueren uC portiert werden soll gibt es nur noch die Hal-Lib. Was soll das ganze dann? Sowas macht nur Sinn, wenn es aufwärtskompatibel bleibt. Alle 3 Jahre was neues zu machen ist doch Schwachsinn. Klar kann man mal schnell was initialisieren. Wenn aber der Punkt kommt wo man mal in die Register des uC schauen muss weil was nicht so geht wie gewünscht, geht die Eierei wieder los. Dann lieber gleich von vornherein nur die Register benutzen, dann weiß man wenigsten was los ist und muss sich nicht noch zusätzlich durch den ST-Code debuggen.
temp schrieb: > Das nenne ich mal einen Witz. Wer in vergangenen Tagen die alte STM-Lib > benutzt hat, wird wohl kein ernsthaftes Projekt auf die neue Hal-Schiene > umstellen können. Du hast es wohl auch noch nicht verstanden. Mit der CubeLibrary kannst du den gleichen Code auf ziemlich vielen STM32 Controllern nutzen. Das hat nichts mit Kompatibilität mit der alten Bibliothek zu tun. Ich finde den Ansatz richtig, die Implementierung und Dokumentation jedoch stark verbesserungsfähig.
avr schrieb: > Du hast es wohl auch noch nicht verstanden. Mit der CubeLibrary kannst > du den gleichen Code auf ziemlich vielen STM32 Controllern nutzen. Jedenfalls solange, bis in irgendeiner Etage bei ST der Chef wechselt und der nächste eine andere Meinung davon hat was die Welt braucht... Ich habe mir die Sachen auch mal angesehen und ein paar Konfigurationen zusammengeclickt. Das ist nur auf dem ersten Blick nett. Was nützt es mir wenn er hinten die komplette PLL Konfiguration raus spuckt und ich keinen Schimmer habe von dem was da abläuft? Mag sein dass manche heute in dieser Beziehung toleranter sind. Ich jedenfalls nicht. avr schrieb: > Das > hat nichts mit Kompatibilität mit der alten Bibliothek zu tun Sag ich doch. Gibt es nicht. Und in 5 Jahren heißt das dann Circle und nicht mehr Cube und es hat wieder nichts mit Kompatibilität zu tun. ST engagiert sich auch ziemlich bei den ganzen mbed - Sachen. Das hat insgesamt gesehen eine ganz schöne Entwicklung gemacht in den letzten Jahren. Heißt der Nachfolger von Cube dann mbed? Aber was soll's, jeder hat das Recht eine Sache so zu machen wie er will. avr schrieb: > Mit der CubeLibrary kannst > du den gleichen Code auf ziemlich vielen STM32 Controllern nutzen Was wohl auch ehr ein Wunschtraum ist. Klar den Takt und ein paar andere Sachen die fast in alles ST32 Controllern gleich sind wie Gpio, Uart u.s.w. Code den man für den Tim1 beim STM32F334 z.B. schreibt wird aber niemals auf einem F103 oder F4 lauffähig werden. Und eins kommt ja auch noch hinzu: man nagelt sich auf ST fest. Nur weil man am Anfang ein paar Stunden gespart hat begibt man sich doch nicht in so ein Korsett. Und wenn man mal eben die Laufzeit in einer schnellen Interruptroutine mit einem GPIO-Pin am LA analysieren will, handelt man sich mit HAL_GPIO_WritePin einen zusätzlichen Funktionsaufruf ein. Noch schlimmer wenn man eine schnelle Umschaltung von Eingang auf Ausgang und zurück braucht und kommt auf die Idee dafür HAL_GPIO_Init zu benutzen. Dümmer gehts nimmer... Was nützt dann der ganze Kram, wenn ich den direkten Weg auch beherrschen muss?
temp schrieb: > Was nützt es > mir wenn er hinten die komplette PLL Konfiguration raus spuckt und ich > keinen Schimmer habe von dem was da abläuft? Mag sein dass manche heute > in dieser Beziehung toleranter sind. Ich jedenfalls nicht. Das ist deine Sache, wenn du das nicht verstehst. Ich weiß was ich tue. Und wer das Zeug nutzt, weil er es nicht anders kann, dem ist auch nicht mehr zu helfen. temp schrieb: > Was wohl auch ehr ein Wunschtraum ist. Klar den Takt und ein paar andere > Sachen die fast in alles ST32 Controllern gleich sind wie Gpio, Uart > u.s.w. Code den man für den Tim1 beim STM32F334 z.B. schreibt wird aber > niemals auf einem F103 oder F4 lauffähig werden. Wenn man Features von einzelnen µCs nutzt darf man sich nicht wundern, wenn genau das nicht portierbar ist... temp schrieb: > Und wenn man mal eben die Laufzeit in einer schnellen Interruptroutine > mit einem GPIO-Pin am LA analysieren will, handelt man sich mit > HAL_GPIO_WritePin einen zusätzlichen Funktionsaufruf ein. Käse. Mit LTO ist da genau gar kein Funktionsaufruf. > Noch schlimmer > wenn man eine schnelle Umschaltung von Eingang auf Ausgang und zurück > braucht und kommt auf die Idee dafür HAL_GPIO_Init zu benutzen. Dümmer > gehts nimmer... Aha, und was hat das genau mit Cube zu tun? Das war bei dem alten HAL genauso. Außerdem sollte man sein Werkzeug kennen. Ansonsten hat man überall verloren. Gib es einfach zu: Du hast die Bibliothek nicht wirklich benutzt. Ich bin mir ihr nicht wirklich zufrieden, aber ich finde sie besser als den Vorgänger. BTW: Ich hab mir mal mbed kurz angeschaut. Allerdings sehe ich da das gleiche wie bei Arduino: Ich kann damit keine 10% der Peripherie nutzen. Alles ist auf ein Minimum vereinfacht. Im Endeffekt muss ich dann doch alles selbst schreiben. Oder täusche ich mich da?
> Was nützt dann der ganze Kram, wenn ich den direkten Weg auch > beherrschen muss? Du wirst auch immer Assembler für spezielle Aufgabenstellungen brauchen. Schreibst du deshalb alles in Assembler?
Jan B. schrieb: > Du wirst auch immer Assembler für spezielle Aufgabenstellungen brauchen. > Schreibst du deshalb alles in Assembler? Kennst du den Unterschied zwischen Äpfeln und Birnen?
Oertel schrieb: > Ordere STM32f0xx. Dann hast du fürs nächste Mal eine Unklarheit > beseitigt. Genau. STM32F0. Für Batteriebetrieb. Urks. Die STM32F0 saufen Strom wie ein verdurstendes Kamel Wasser. Wenn schon STM32, dann die L0-Serie: http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1817?icmp=ss1817_pron_pr_feb2014 ST weiß schon, warum sie eine eigene Serie auflegen ;-) Also: STM32 L0 taugen. PIC24 gehen hervorragend. MSP430 sind auch super. Bei ATMEL kann ich dir nicht weiterhelfen. Ich an deiner Stelle würde bei den Tinys bleiben. Wenn das tut, warum nicht dabei bleiben?
Markus M. schrieb: > Außerdem, was hat den der M2560 bei Millionen typischer kleiner MS(R) > Anwendungen verloren? In diesem Thread: Nichts. Ich hab den auch nicht in die Diskussion gebracht.
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.