Hallo zusammen! Ich benutze seit ca. 5 Jahren meistens AtMega168/328 und 2560 in kombination mit der Arduino Software für meine Projekte Damit habe ich seit Anfang folgende Probleme - Kleine Anzahl der Eingänge, oft muss ein Port-Expander her - Relativ kleiner Speicher beim 168/328, sobald ein Grafik-Display involviert ist, ist die Hälfte des speichers futsch - Relative langsame Geschwindigkeit. Da die Arduino-Software relativ "lange" für Aktionen braucht, ist 16Mhz nicht grade die Welt! Nun ist es mitlerweilen so das die 328 bei den meisten Lieferanten etwa um die 3-4$, und die 2560 umd die 15$ im QFP-Gehäuse kosten. Reichelt fällt für mich leider flach, wohn in der Schweiz. Ich überlege mir nun, in nächster Zeit auf ein anderes System umzusteigen. Ich habe bereits mal im Internet geschaut, und bin auf STM gestossen. Das schöne wäre, das z.b. STM32F103 auch Arduino-kompatibel ist, und etwa um die 4$ kostet. Ein kurzer blick auf die STM-Software mbed, lässt grosse ähnlichkeiten zu Arduion erkennen, möglicherweise währe ein späteres "umlernen" auf die mbed-Sprache auch keine zu grosse Herausforderung. Eines der Hauptprobleme ist, wenn man von Arduino weggeht. Sobald man ein Projekt veröffentlich, welches mit einer eher "unbekanten" Software realsiert wurde, sinkt das Intresse anderer daran. Gerade bei Projekten die einen eher "optischen" Nutzen haben z.b. "LED Beleuchtungen", da diese meist auch von Bastlern eingesetzt werden, die nur die einfachsten Kenntnisse haben. Kommentare wie "Why no Arduino-Software" or "i would buy it, if it has arduino on it" kenne ich bereits. Darum tendiere ich aktuell zu STM *Spricht etwas dagegen? Das einzige was ich aktuell ein Problemchen sehe, sind 72MHz. Viele Leute sagen ja, ab etwa 25MHz können Quarze richtig Probleme machen, wenn man kein perfektes Layout hat. Hat jemand erfahrung mit selbst designten Boards mit STM-Controllern? Gibt es sonst bekannte Vor/Nachteile von STM? Gäbe es noch weitere Platformen, die von der Schwierigkeit ähnlich zu lernen währen? Der Preis spielt natürlich auch ein Rolle, je günstiger je besser ;). Bei der Baugrösse sollte es am besten QFP sein, da das einigermassen klein ist, aber noch gut und schön handlötbar ist.
:
Bearbeitet durch User
Johnny S. schrieb: > Das einzige was ich aktuell ein Problemchen sehe, sind 72MHz. Die STM32 haben eine PLL. Man verwendet einen Quarz geringer Frequenz (zB 8 MHz) und die wird intern hoch multipliziert. Das Layout des Quarzes ist kein großes Problem. Man kann ja auch (Keramik) Oszillatoren nehmen, da kann man noch weniger falsch machen. Wenn man keine asynchronen Interfaces (UART, CAN) verwendet reicht evtl. auch der interne Oszillator. Ich würde aber nicht mit einem F1 anfangen, denn das ist die älteste Reihe. Lieber mit den neuen, wie L0, L1, F3, oder F7 - denn bei denen ist u.a. die I2C Peripherie viel besser. Mit dem STM32 Olimexino gibt es ein Arduino kompatibeles STM32 Board sogar mit Arduino artiger Software.
Johnny S. schrieb: > Das einzige was ich aktuell ein Problemchen sehe, sind 72MHz. Viele > Leute sagen ja, ab etwa 25MHz können Quarze richtig Probleme machen, > wenn man kein perfektes Layout hat. Hat jemand erfahrung mit selbst > designten Boards mit STM-Controllern? Der STM32 hat eine PLL, d.h. die Quarz-Frequenz kann niedrig sein und wird dann intern hochmultipliziert. Viele Grüße, Stefan
Johnny S. schrieb: > - Relative langsame Geschwindigkeit. Da die Arduino-Software relativ > "lange" für Aktionen braucht, ist 16Mhz nicht grade die Welt! Sorry, aber wer Arduino nutzt und sich über langsam aufregt, ist selber schuld. Natürlich verballert das Software-Framework 90% der Rechenleistung, dafür ist es ja auch ohne Intelligenz einsetzbar. Johnny S. schrieb: > - Kleine Anzahl der Eingänge, oft muss ein Port-Expander her Der ist normalerweisse billiger als ein uC mit mehr Anschlüssen. Johnny S. schrieb: > Relativ kleiner Speicher beim 168/328, sobald ein Grafik-Display > involviert ist, ist die Hälfte des speichers futsch Ja, für Graphik halte ich AVR auch nicht für geeignet. Johnny S. schrieb: > Eines der Hauptprobleme ist, wenn man von Arduino weggeht. Sobald man > ein Projekt veröffentlich, welches mit einer eher "unbekanten" Software > realsiert wurde, sinkt das Intresse anderer daran. Ja nun, du bastelst nur damit andere dich gut finden ? Kann man als Lebensziel haben. Johnny S. schrieb: > Das einzige was ich aktuell ein Problemchen sehe, sind 72MHz. Viele > Leute sagen ja, ab etwa 25MHz können Quarze richtig Probleme machen, > wenn man kein perfektes Layout hat. Der Quartz hat gar keine 72MHz, stagten schon andere. Das Plastinenlayout (vor allem Versorgungsspannungsführung und Abblockkondensatoren) muss natürlich zur Abpufferung der schnellen Schaltvorgänge trotzdem viel besser sein als beim gutmütigen AVR.
Johnny S. schrieb: > Das einzige was ich aktuell ein Problemchen sehe, sind 72MHz. Die intern verwendeten 72Mhz werden durch PLL aus 8Mhz o.ä. gebildet. Daher eher problemlos im Design, ausser du benötigst für spez. Anwendungen wie LAN-IC, SDIO-Cam oder GLCD den abgeleiteten Takt. Auch USB Layout ist empfindlich im routen. Die Einschränkung, wenige I/O, gilt ohne Expander wie MCP23(0/S)17 auch für den ESP8266. Arduino erprobt ist er auf alle Fälle. Beitrag "ESP8266 mit SPI-Display" Der ESP32 bietet da andere Möglichkeiten ..
Johnny S. schrieb: > Ich benutze seit ca. 5 Jahren meistens AtMega168/328 und 2560 in > kombination mit der Arduino Software für meine Projekte > > Damit habe ich seit Anfang folgende Probleme > > - Kleine Anzahl der Eingänge, oft muss ein Port-Expander her Es sind doch immer zu wenig Eingänge. Andererseits sind Portexpander flexibler und billiger als µC mit mehr Pins. Zumal letztere dann in Gehäusen kommen, die man nicht mehr bastlermäßig bestücken kann. > - Relativ kleiner Speicher beim 168/328, sobald ein Grafik-Display > involviert ist, ist die Hälfte des speichers futsch Verstehe ich nicht. Welcher Speicher? RAM? Flash? Und wieso "futsch"? Entscheidend ist doch nur, ob der Speicher noch reicht. Und ein ATmega168 ist ja bei weitem nicht das Ende der Fahnenstange, selbst wenn man in der ATmega Familie bleibt. > - Relative langsame Geschwindigkeit. Da die Arduino-Software relativ > "lange" für Aktionen braucht, ist 16Mhz nicht grade die Welt! Dann lern halt erst mal, richtig zu programmieren. Daß das Arduino- Framework langsam ist, pfeifen die Spatzen von den Dächern. > Ich überlege mir nun, in nächster Zeit auf ein anderes System > umzusteigen. > > Ich habe bereits mal im Internet geschaut, und bin auf STM gestossen. > Das schöne wäre, das z.b. STM32F103 auch Arduino-kompatibel ist Eigentlich ist es anders herum. Arduino ist auch STM32-kompatibel. Intern ist das eine ganz andere Architektur. Aber die Arduino-Leute haben ihren Kram dahin portiert und deswegen sieht es durch die Arduino-Brille so aus, als hätte sich kaum was geändert. Faktor 10 langsamer als nötig ist es aber immer noch. > Eines der Hauptprobleme ist, wenn man von Arduino weggeht. Sobald man > ein Projekt veröffentlich, welches mit einer eher "unbekanten" Software > realsiert wurde, sinkt das Intresse anderer daran. 1. wen juckt das? 2. stimmt nicht. Bzw. stimmt nur dann, wenn man seine Follower in der Arduino-Community sucht. Aber das will man eigentlich gar nicht. Arduino ist wie Lego. Irgendwann wächst man aus dem Lego-Alter heraus. > Darum tendiere ich aktuell zu STM *Spricht etwas dagegen? Nein. Nachdem Microchip gerade die Preise für AVR anhebt und damit deutlich vor Augen führt wie schlecht es ist, wenn eine Architektur nur von einem Hersteller angeboten wird, wird ARM von Tag zu Tag attraktiver. Ob du dich nun für STM32 von ST entscheidest oder eine der Alternativen von NXP, Infineon, Freescale, Cypress oder ... , sei dahingestellt.
Dr. Sommer schrieb: > Die STM32 haben eine PLL. Man verwendet einen Quarz geringer Frequenz > (zB 8 MHz) und die wird intern hoch multipliziert. Sehr gut! Hört sich toll an, aktuell verwende ich immer einen 16 MHz und hatte nie Probeleme. Also ist das "Problem" schon mal vom Tisch. MaWin schrieb: > Der ist normalerweisse billiger als ein uC mit mehr Anschlüssen. Nunaj, ein AtMega 328 kostet mich 3-4$, und hat 13 Digital-IO und 5 Analog. Ein STM32 hat 51 I/O, und kostet um 4$. Ein 16bit Portexpander kostet ca 0.7$. > Ja, für Graphik halte ich AVR auch nicht für geeignet. Nunja, das mag sein. Nur gibt es für Arduino halt viele Librarys für Displays. 2x16 LCD, div. Oled-Grafik, EA DOG-Serie usw. Axel S. schrieb: > Verstehe ich nicht. Welcher Speicher? RAM? Flash? Und wieso "futsch"? > Entscheidend ist doch nur, ob der Speicher noch reicht. Und ein > ATmega168 ist ja bei weitem nicht das Ende der Fahnenstange, selbst wenn > man in der ATmega Familie bleibt. Beim Atmega328 sind beim einsatz einer Grafik-Library und einer Encoder-Library bereits 54% von 2kBytes belegt, ohne das man irgendwelchen Code geschrieben hat. Kommt dann z.b. noch die Ethernet-libaray dazu, fängt man sich langsam Gedanken zu machen, auf welche Funktionen man verzichten kann. > Eigentlich ist es anders herum. Arduino ist auch STM32-kompatibel. > Intern ist das eine ganz andere Architektur. Aber die Arduino-Leute > haben ihren Kram dahin portiert und deswegen sieht es durch die > Arduino-Brille so aus, als hätte sich kaum was geändert. Faktor 10 > langsamer als nötig ist es aber immer noch. Das mag stimmen. Dafür müsste ich aber nichts umlernen. > 1. wen juckt das? > 2. stimmt nicht. Bzw. stimmt nur dann, wenn man seine Follower in der > Arduino-Community sucht. Aber das will man eigentlich gar nicht. Arduino > ist wie Lego. Irgendwann wächst man aus dem Lego-Alter heraus. 1. Mich :) 2. Nunja, das sehe ich anders. Das schöne an Arduino ist für mich folgendes: Man kann, als kompletter elektrischer Laie, ein Board und z.b. einen LED-Ring kaufen, und hat auch ohne Vorkenntnisse innert 2-3h ein funktionierendes Ergebniss. Wir hatten damals (Anno 2012) in der Berufschulekurse in PIC Microcontrollern von Microchip (MpLab hiess die Programmierobefläche), das war für 75% der Lehrlinge so komplex und langweilig, das die den Kurs nach wenigen Tagen beended wurde. Grade am Anfang finde ich einfachheit wichtig, um nicht die lust zu verlieren. Um bei MpLab ein einen Text auf einem LCD anzuzeigen, brauchte man damal ungelogen etwa 1.5 A4 seiten mit Anweisungen. Bei Arduino ist das insgesamt vieleicht ein 5-Zeiler Code. > Nein. Nachdem Microchip gerade die Preise für AVR anhebt und damit > deutlich vor Augen führt wie schlecht es ist, wenn eine Architektur nur > von einem Hersteller angeboten wird, wird ARM von Tag zu Tag > attraktiver. Ob du dich nun für STM32 von ST entscheidest oder eine der > Alternativen von NXP, Infineon, Freescale, Cypress oder ... , sei > dahingestellt. Wie sind denn die Programmieroberflächen der anderen Hersteller so? Ähnlich wie mbed? Mbed sagt mir vom aussehen relativ gut zu. Eines meiner Probleme ist sicher, das ich eher der "zusammenbauer" bin, ich hab mehr die Freude am Layouts erstellen und Zeug auflöten, mit Programmieren tu ich mich eher schwer :) Da ich eh bald wieder bei Digikey bestell, hätt ich mir mal so ein board zum rumspielen geholt: http://www.digikey.com/product-detail/en/stmicroelectronics/NUCLEO-F303RE/497-15105-ND/5052640 Bei 11$ ist auch nicht so schlimm wenns nix taugt
:
Bearbeitet durch User
Johnny S. schrieb: > Grade am Anfang finde ich > einfachheit wichtig, um nicht die lust zu verlieren. Das sehe ich auch so. Der große Vorteil bei Arduino ist: der Code ist echtes C++, anfängerfreundlich verpackt durch die libraries und das Eliminieren von .h Files. Der Umstieg auf "echtes" C++ ist überschaubar. Früher haben die Anfänger Basic programmiert und die Freaks haben dann mit peek / poke gehackt. Da war die Hürde, tiefer einzusteigen, extrem hoch. Johnny S. schrieb: > Da ich eh bald wieder bei Digikey bestell, hätt ich mir mal so ein board > zum rumspielen geholt: Das Board hat einen integrierten Debugger an Board. Damit kannst Du Breakpoints setzen, Variablen anschauen, etc. Aber nicht mit Arduino, das kannst Du z.B. mit Coocox machen. Kleines Problem: wenn Du Dich an echtes Debugging einmal gewöhnt hast, willst Du nicht mehr zu Arduino zurück ... Viele Grüße, Stefan
Axel S. schrieb: > Eigentlich ist es anders herum. Arduino ist auch STM32-kompatibel. > Intern ist das eine ganz andere Architektur. Aber die Arduino-Leute > haben ihren Kram dahin portiert und deswegen sieht es durch die > Arduino-Brille so aus, als hätte sich kaum was geändert. Faktor 10 > langsamer als nötig ist es aber immer noch. Diese Aussage ist einfach Schwachsinn. Die Arduino Schicht ist nicht viel dicker als die der unsägliche HAL beim STM32. Wer in größtmöglicher Geschwindigkeit mit den Pins wackeln will kann selbstverständlich auch in einer Arduino Umgebung mit den Registern arbeiten. Für ein paar Byte seriell oder über SPI/I2C spielt diese Schicht dazwischen überhaupt keinen nennenswerte Rolle. Und für zeitkritische Sachen steht es jeden frei das auf direktem Weg zu erledigen. Einzig die Arduino Entwicklungsumgebung ist zäh. Die brauch aber keiner zu benutzen.
Angehängte Dateien:
-
leaflab.jpg
320 KB
Hmmmmmm, wenn man "unbedingt" STM32 machen mag und dann mbed bei wenigen Kosten haben will, dann dürfte als Board dieses hier wohl oki sein: http://www.ebay.de/itm/STM32F103RCBT6-ARM-Cortex-M3-leaflabs-Leaf-maple-mini-module-for-arduino-STM32-F-/272041589086?hash=item3f56f1395e:g:KfEAAOSwgY9XedZS Dieses Teil funktioniert mit mbed relativ gut, wenn man das Board NICHT über den integrierten Bootloader, sondern mittels ST-Link V2 flasht (hier ist dann jedoch mittels eines Utilites von ST der bereits aufgespielte Bootloader zu entfernen. Zu beachten ist hier dann auch, dass ein erstelltes Programm NICHT mittels Drag und Drop auf ein Board kopiert werden kann, sondern mittels des eigenem ST-LINK v2 Programm zu geschehen hat. Als Board in mbed wählt man das Nucleo-F103RB. Wer das Onlineprogrammieren nicht mag, kann sich ein in mbed angelegtes Projekt nach arm-none-eabi-gcc konvertieren lassen und dieses mittels Editor und Makefile weiter bearbeiten. Belässt man bei diesem Board den Bootloader, kann man die (mittlerweile eingestellte) Maple-Leaf-Lab IDE verwenden (schmunzel, die dem Arduino-IDE Liebhaber sicherlich gefällt). Die Maple-Leaf-Labs IDE bekommt man hier: http://docs.leaflabs.com/docs.leaflabs.com/index.html Ein weiteres Board (noch preiswerter, allerdings auch nur 64 kByte Flash) ist: http://www.ebay.de/itm/STM32F103C8T6-ARM-STM32-Minimum-System-Development-Board-Module-For-Arduino-/172113793450?hash=item2812c811aa:g:74YAAOSwZ8ZW5jfe Dieses funktioniert mit der Leaf-Labs IDE nicht (fehlender Bootloader), jedoch immer noch mit mbed... allerdings sollte hier darauf geachtet werden, dass ein Programm nicht größer als 64 kByte wird... Oder mit mbed ein Projekt exportieren und in den Dateien die Linkerscripts und Startup-Files anpassen. Einen passenden ST-Link v2 "Flasher" gibts hier: http://www.ebay.de/itm/ST-Link-V2-Programming-Unit-mini-STM8-STM32-Emulator-Downloader-M89-CF-/272154524822?hash=item3f5dac7c96:g:j0wAAOSwh-1W15Zx Letztlich gilt allerdings: Wer mittels den IDE's programmiert, sei es nun Arduino oder mbed bleibt, hat sich mit dem Controller nicht wirklich auseinander gesetzt (aus meiner Sicht jedoch auch legitim wenn es um das Ergebnis geht und etwas funktioniert). Schöne "Übung" ist sicherlich, sich ein mbed Projekt zu exportieren und sich diese Dateien für seine Zwecke anzupassen (hier erfolgt dann zwangsläufig der Blick ins Datenblatt). Ansonsten, wenn man mbed verwenden möchte, sind die absolut preiswerten ST Nucleo Boards zu empfehlen, allen voran das Nucleo F411RE. :-) man muß ja nicht zwingend mbed verwenden.
Johnny S. schrieb: > Nunaj, ein AtMega 328 kostet mich 3-4$, und hat 13 Digital-IO und 5 > Analog. So nen Quark... der hat bei 28 Pins insgesamt 23 Programmable I/O Lines - davon können 8 ADC. Das ist wenn man über seinen Arduino Tellerrand nicht rausschauen kann! Der Rest ist 2xGND, VCC, AVCC, AREF.
Johnny S. schrieb: > Da ich eh bald wieder bei Digikey bestell, hätt ich mir mal so ein board > zum rumspielen geholt: > > http://www.digikey.com/product-detail/en/stmicroelectronics/NUCLEO-F303RE/497-15105-ND/5052640 Für 2 Euro mehr gibts dort auch einen F401RE ... Beiden gemeinsam ist jedoch, dass du über dieses Teil durch umstecken der Jumper an der oberen Reihe dieses zum Programmieren eines jeden STM32 Controllers verwenden kannst, sei es nun ein extrem billiges Chinaboard wie oben genannt, oder einen Stand-Alone Chip wie einen STM32F030 (der dann aufgrund des geringen Flash-Speichers kaum mehr mittels eines Frameworks wie Arduino, Leaflabs oder mbed programmiert werden kann). Vllt. solltest du dich zumindest mal (wenn schon STM32) wenigstens mit der - aus meiner Sicht sehr übersichtlich aufgebauten - Library libopencm3 beschäftigen. Hiermit ist wirklich ein guter Einstieg in ARM möglich und du wirst dennoch schnell damit beginnen dich in die Register einzuarbeiten...
> Sobald man ein Projekt veröffentlich, welches mit einer eher > "unbekanten" Software realsiert wurde, sinkt das Intresse anderer > daran. Na und? Willst du aufgrund deiner Veröffentlichungen berühmt werden oder mit deiner Arbeit Geld verdienen? Wenn es ums Geld verdienen geht, dann sollte dieser Aspekt vollkommen egal sein. Wenn du berühmt werden willst, dann produziere Katzenvideos für Youtube. Oder mach was verrüktes, zum Beispiel eine Burg kaufen uns rosa anmalen. > Darum tendiere ich aktuell zu STM. Spricht etwas dagegen? Nein, mach ruhig. Wenn mir meine AVR's nicht mehr ausreichen werde ich auch STM nehmen. Ich bin allerdings kein Freund von Arduino.
Ralph S. schrieb: > Hmmmmmm, wenn man "unbedingt" STM32 machen mag und dann mbed bei wenigen > Kosten haben will, dann dürfte als Board dieses hier wohl oki sein: > > Ebay-Artikel Nr. 272041589086 Jedenfalls solange man nichts mit USB machen möchte. Leider wird usb von mbed bei der STM32F1-Serie nicht unterstützt. Das beim Arduino Port besser, da gibts usb-cdc, midi, hdi, und storage.
temp schrieb: > Jedenfalls solange man nichts mit USB machen möchte. Leider wird usb von > mbed bei der STM32F1-Serie nicht unterstützt. Das beim Arduino Port > besser, da gibts usb-cdc, midi, hdi, und storage. Ich mache kein Arduino, aber grundsätzlich ist beim "Standard-Arduino", dem UNO oder Nano, ein ATmega328 drauf, der keine USB Unterstützung hat. D.h. jegliches USB wird hier dann wohl mittels V-USB realisiert (und das mache ich, wenn überhaupt, dann doch lieber ohne das Arduino Framework). mbed unterstützt bei den STM32F4 auch USB (von anderen Controllern weiß ich es nicht). Nur um es klar auszudrücken: mbed wird auch eine Menge Power schlucken, weil einiges im Framework stecken bleibt. Wirklicher Nachteil hier ist dann allerdings, dass man ONLINE programmiert (in einem Webfenster) mit sehr eingeschränkten Möglichkeiten. Dann schon lieber, wie gesagt, das ganze Projekt exportieren (mit sämtlichen Libraries die man benötigt) um dann mit einem Editor der Wahl seine Anwendung zu programmieren. Oder vielleicht Eclipse basierende IDE ? (hat alles zusammen das Potenzial für einen "Glaubenskrieg"). Zum lernen und verstehen: Editor und Makefile.
temp schrieb: > Axel S. schrieb: >> Eigentlich ist es anders herum. Arduino ist auch STM32-kompatibel. >> Intern ist das eine ganz andere Architektur. Aber die Arduino-Leute >> haben ihren Kram dahin portiert und deswegen sieht es durch die >> Arduino-Brille so aus, als hätte sich kaum was geändert. Faktor 10 >> langsamer als nötig ist es aber immer noch. > > Diese Aussage ist einfach Schwachsinn. Die Arduino Schicht ist nicht > viel dicker als die der unsägliche HAL beim STM32. Wow. Deine Aussage ist noch viel schwachsinniger. Wenn ich sage "Framework X ist lahm" dann ist dein "das macht nichts, Framework Y ist fast genauso lahm" kein Gegenargument. Man würde natürlich nicht diesen HAL-Dreck von ST nehmen. Statt dessen würde man auch auf dem AVR direkt auf die Hardware zugreifen und auf einmal wäre der AVR mehr als schnell genug und es gäbe gar keinen Grund, auf ARM umzusteigen.
Johnny S. schrieb: > Wie sind denn die Programmieroberflächen der anderen Hersteller so? > Ähnlich wie mbed? Mbed sagt mir vom aussehen relativ gut zu. Oben links auf dieser Seite ist ein Link "ARM". Da klickst du jetzt mal drauf und liest ein bißchen. Es gibt ungefähr genauso viele IDE für ARM wie es Hersteller gibt. Plus gefühlt 100 weitere, die nicht spezifisch für einen Hersteller sind. Wenn du auf ARM umsteigen willst und gleichzeitig von Arduino weg, dann würde ich eine der herstellerunabhängigen IDE empfehlen. Wenn du bei STM32 bleiben willst, ist das Zeug von ST vielleicht auf den ersten Blick komfortabler, langfristig bindet es dich aber auch wieder an einen Hersteller. Und ST hat dieses unsäglich schlechte HAL, das man nicht verwenden will.
Axel S. schrieb: > Wow. Deine Aussage ist noch viel schwachsinniger. Wenn ich sage > "Framework X ist lahm" dann ist dein "das macht nichts, Framework Y ist > fast genauso lahm" kein Gegenargument. > > Man würde natürlich nicht diesen HAL-Dreck von ST nehmen. Statt dessen > würde man auch auf dem AVR direkt auf die Hardware zugreifen und auf > einmal wäre der AVR mehr als schnell genug und es gäbe gar keinen Grund, > auf ARM umzusteigen. Jetzt sind wir schon bei der 3 Potenz von Schwachsinn... Die STM32 Hal -oder Stdlib ist aber leider das was zu 99% hier im Forum benutzt wird. Deshalb ist es legitim das als Vergleich zu nehmen. Kannst ja mal nach Codeschnipseln suche die den STM32 auf Registerbasis benutzen. Da wirst du hier und im restlichen Netz nicht fündig. Das ist bei NXP z.B. nicht so. Schaut euch mal die meisten Projekte hier im Forum an. Irgendwelche Steuerungssachen die mit den Pins mal ein paar Leds oder Relais bedienen. Daneben die übliche Kommunikation wie SPI/I2C/CAN. Denkst du wenn ich die SPI-Initalisierung selber schreibe wird die schneller als in der Lib? Oder wird der CAN-Bus langsamer weil ich eine Lib-Funktion SendMsg() aufrufe? Oder ist das irgendwo relevant? Die Geschwindigkeit ist meistens sowieso nicht das Maß der Dinge. Jedenfalls ist das nicht das Kriterium was mich vom AVR zum Arm bringen würde. Um über mbed zu urteilen muss man die Konzepte und deren Realisierung erst mal verstehen. Vieles ist da deutlich besser als bei Arduino, libopencm3 u.s.w gelöst. Man muss keine Lib benutzen klar, aber Arduino verteufeln und vorwerfen das schluckt massenhaft Performance zeugt nur von Dummheit. Ralph S. schrieb: > Nur um es klar auszudrücken: mbed wird auch eine Menge Power schlucken, > weil einiges im Framework stecken bleibt. Das ist auch eine sehr gewagte Aussage. Hast du mal an Beispielen gemessen von was wir hier sprechen? > Wirklicher Nachteil hier ist > dann allerdings, dass man ONLINE programmiert (in einem Webfenster) mit > sehr eingeschränkten Möglichkeiten. Das kann man machen, muss es aber nicht. mbed genauso wie Arduino kann man auch komplett mit allen Qellen in jeder IDE seiner Wahl benutzen und debuggen. Dazu darf man aber nur nicht ganz auf den Kopf gefallen sein. Ralph S. schrieb: > D.h. jegliches USB wird hier dann wohl mittels V-USB realisiert (und das > mache ich, wenn überhaupt, dann doch lieber ohne das Arduino Framework). Ich spreche vom STM32 Arduino Port. Da ist nichts mit V-USB. AVR ist mir sowas von Wumpe. Ungefähr soweit weg wie U880 und Z8.
Ralph S. schrieb: > Zum lernen und verstehen: Editor und Makefile. Keine Einwände dagegen. Fehlt nur noch ein Debugger der binaries die auf diesem Weg erzeugt wurden auch verwenden kann. Ich habe seit Jahren Crossworks und bin damit sehr zufrieden. Neuerdings gibts auch Segger Embedded Studio das wohl von Crossworks stammt. Da die stlinkv2's alle in den jlink-Modus gebracht werden können ist das auch eine gute Alternative.
temp schrieb: > Axel S. schrieb: >> Wow. Deine Aussage ist noch viel schwachsinniger. Wenn ich sage >> "Framework X ist lahm" dann ist dein "das macht nichts, Framework Y ist >> fast genauso lahm" kein Gegenargument. > > Jetzt sind wir schon bei der 3 Potenz von Schwachsinn... Die STM32 Hal > -oder Stdlib ist aber leider das was zu 99% hier im Forum benutzt wird. > Deshalb ist es legitim das als Vergleich zu nehmen. Es ging nur um überhaupt keinen Vergleich. Ich habe gesagt: Axel S. schrieb: > die Arduino-Leute > haben ihren Kram dahin portiert und deswegen sieht es durch die > Arduino-Brille so aus, als hätte sich kaum was geändert. Faktor 10 > langsamer als nötig ist es aber immer noch. Low-Level Operationen wie DigitalWrite() sind um Faktor 10 langsamer als sie sein könnten. Daß du jetzt ein Ranz-Framework nennen kannst (oder meinetwegen auch 100 solche) das ähnlich langsam ist, ändert doch überhaupt gar nichts an meiner Aussage. Ja, die sind dann auch alle langsamer als nötig. Noch dazu war mit meiner Aussage gar keine Wertung verbunden. Das war ganz einfach eine Feststellung, die mir deswegen nötig erschien weil der TE extra hevorgehoben hat, er würde zu Arduino/ARM wechseln wollen, weil ihm Arduino/AVR zu langsam ist.
Axel S. schrieb: > Low-Level Operationen wie DigitalWrite() sind um Faktor 10 langsamer als > sie sein könnten. Da geb ich dir völlig Recht. Nur interessiert das meistens niemanden weil das Pin-Wackeln nur in den seltesten Fällen eine zeitkritische Angelegenheit ist. Zeitkritisches Pinwackeln machen die Hardwareeinheiten wie Timer u.ä. auf einem cortex. Wer hier versucht Assemblerbefehle zu zählen und damit das Zeitverhalten auszurechnen, der sollte beim AVR bleiben. Es steht jedem aber frei auch unter Arduino, mbed oder wie sie sonst alle heißen auch die Pins direkt mit den Registern zu schalten. Trotzdem, wer mit GPIO Toggeln z.B. Impulse für Servos erzeugen will macht was falsch. Der Vorteil von DigitalWrite() ist aber, dass er auf allen Plattformen die Arduino unterstützt gleich ist. Viele der Codeschnipsel die das Internet hergibt sind damit kompatibel zwischen den verschiedenen avr und stm32 Varianten. Man kann sich auch gern mal den Arduino-Port für den ESP8266 ansehen. Da es hier sowieso nicht viele Pins gibt werden die Programme die darauf laufen auch nicht so umfangreich sein. Das übliche halt, ein paar Sensordaten zu einem Server schicken oder aus dem WLAN Befehle entgegennehmen und Aktionen auslösen. Weder macht das den sowieso schon großen Code nennenswert dicker noch behindert es den ESP so sehr dass man es merkt. Für mal ein paar kleine Sachen zwischendurch lohnt sich die Einarbeitung in das umfangreiche SDK zum Esp8266 nicht. Für Geräte in großen Stückzahlen sieht die Sache schon anders aus. Da kann der Einsatz einer der o.g. Libs dazu führen, dass man ein paar Cent für einen Controller mit mehr Flash drauflegen muss. Aber ich glaube da sind wir uns einig, das was wir hier diskutieren ist für den Bastlerbereich relevant. Wenn es um Großserie geht gelten ganz andere Kriterien. Axel S. schrieb: > weil > ihm Arduino/AVR zu langsam ist Das kann ja sein. Mach mal umfangreiche float oder double Berechnungen auf dem AVR. Da kann ein Stm32F4 mal eben locker einen Faktor 100 bringen. Ob die ADC Werte dann mit einer Funktion aus einer Lib abgeholt werden oder mit Registerschubsen ist zeitlich nicht besonders relevant, die Berechnungen aber schon.
Ist das schlimm? Mit den Atmel Chips bindet man sich ja auch an einen Hersteller. Und was programmiert ihr bitte, als das man Sorge haben müsste da durch eine Framework ausgebremst zu werden(gerade auf dem STM32ern)? Bei den STM32F2 benutze ich CMSIS. Ist kein AbstractionLayer ist sondern eher unmengen an Defines. So wie ich das verstehe, macht der TO das nur als Hobby...also was spricht dagegen sich in einen neuen Controller einzuarbeiten. Mit den Discoveryboards kann man gut erste Erfahrungen sammeln
> Ich benutze seit ca. 5 Jahren meistens AtMega168/328 und 2560 in > kombination mit der Arduino Software für meine Projekte > Damit habe ich seit Anfang folgende Probleme Seit fuenf Jahren in der Gummizelle. Und kein Ansatz von Dir mal zu sehen ob die Tuer offen ist. > Wir hatten damals (Anno 2012) in der Berufschulekurse in PIC > Microcontrollern von Microchip (MpLab hiess die Programmierobefläche), > das war für 75% der Lehrlinge so komplex und langweilig, das die den > Kurs nach wenigen Tagen beended wurde. Grade am Anfang finde ich > einfachheit wichtig, um nicht die lust zu verlieren. Du bist nach fuenf Jahren scheinbar immer noch am Anfang. Du solltest Dir ein anderes Hobby suchen.
Johnny S. schrieb: > Eines der Hauptprobleme ist, wenn man von Arduino weggeht. Sobald man > ein Projekt veröffentlich, welches mit einer eher "unbekanten" Software > realsiert wurde, sinkt das Intresse anderer daran. Johnny S. schrieb: > das war für 75% der Lehrlinge so komplex und langweilig, das die den > Kurs nach wenigen Tagen beended wurde. Grade am Anfang finde ich > einfachheit wichtig, um nicht die lust zu verlieren. Gehe mal ganz in Ruhe in dich und frag dich, was du eigentlich willst. Willst du in irgend einer Szene z.B. Arduino vor anderen glänzen und dürstest nach Lob? Willst du irgendwelche tatsächlichen Dinge schaffen, also irgend etwas mit anschließendem echten Gebrauchswert? Willst du was lernen, um in einem einschlägigen Fach beruflich weiter zu kommen? Willst du nur deine Freizeit mit etwas ausfüllen, das dir interessant genug vorkommt? Die nächsten Fragen warten dann schon: wenn du weißt, was du willst, dann frag dich, was du kannst, also wie weit deine Kenntnisse und Fertigkeiten gediehen sind. Es gibt so viele Fragen, die du dir selber stellen müßtest, um dir Klarheit über deine Ziele zu verschaffen und deine Prioritäten zu ordnen. Dein Bericht über den PIC-Lehrgang ist durchaus aufschlußreich und meine Ansicht über derartige Themen differiert von den weiter oben dazu geäußerten Ansichten vollständig. Den Spruch "Mädezehn moss bättr sein, sonst nötzt sää nächt" kennst du vielleicht aus dem Kino. Ich halte es damit ähnlich: Die Notwendigkeit, sich selbst etwas zur Sache beizubringen und nicht zu erwarten, daß immer alles nur kurzweilig und Spaß-Spaß-Spaß ist und einem von Lehrern irgendwo reingeschoben wird, ist eine Art gesellschaftlicher Hygienemaßnahme, die dazu führt, daß Leute, die eben nicht den inneren Drang in das betreffende Fachgebiet haben, das Ganze langweilig oder stressig finden und sich was Anderes suchen. Das ist GUT SO. Leicht geht es eben nur dann, wenn man selbst sich Kenntnisse und Fertigkeiten angeeignet hat. Das Schlaraffenland ist nur eine Mär. Ansonsten ist es ne Geschmackssache, ob man nun eher zu ST oder NXP tendiert. Sowas klärt man dann, wenn man sich bei einem Projekt im Klaren ist, was man an Signalen, Peripherie und Funktionalität benötigt. Die jeweiligen RefManuals und Datenblätter zu den Chips muß man sowieso lesen. Da liegt NXP mit seinen eigenen Produkten (also LPCxxxx) mMn deutlich vor ST. Das Gegenteil gilt für die von NXP übernommenen Freescale-Chips. Deren Dokumentation finde ich gräßlich - aber da gibt's Leute, die wiederum dazu das Gegenteil behaupten. Von Infineon und dem Rest der Szene würde ich eher abraten, entweder schwer beschaffbar oder technisch eigenartig oder ne Extrabratwurst bei den Tools oder alles zusammen. W.S.
W.S. schrieb: > Das Gegenteil gilt für die von NXP übernommenen > Freescale-Chips. Deren Dokumentation finde ich gräßlich - aber da gibt's > Leute, die wiederum dazu das Gegenteil behaupten. Trotzdem ist die KE06 Serie von Freescale nicht uninteressant. Einmal weil sie direkt mit 5V laufen und zum anderen sind die Gehäuse für Grobmotoriker oder Augenschwache besser lötbar. Preiswerte Entwicklungsboards Boards gibst auch.
W.S. schrieb: > Deren Dokumentation finde ich gräßlich - aber da gibt's > Leute, die wiederum dazu das Gegenteil behaupten. Da zähle ich mich gerade mal dazu - ich hab' da noch nix nicht gefunden, wenn ich's brauchte.
temp schrieb: > Trotzdem ist die KE06 Serie von Freescale nicht uninteressant. Sehe ich zwar auch so, aber da diese Reihe die separaten Register zum Zuordnen der Pinfunktionen/Alternativfunktionen eben NICHT hat, hab ich die vorhandenen Muster nebst Eval-Platinen erstmal in den Hades verbannt. Mich widert es maßlos an, zwecks Definieren einer Pinfunktion erstmal durch sämtliche peripheren Cores zu tingeln. Ichhalte aus diesem Grunde alle drei MKE-Reihen für Fehlgeburten. Aber das ist man bei Freescale gewöhnt. Siehe das Takt-Drama bei den Typen mit USB. Warum sind diese Eierköpfe bloß zu unfähig, eine echte PLL mit Referenzfrequenzen im MHz Bereich zu bauen und kommen stattdessen mit ihrer FLL, die von 32..39 kHz gespeist werden muß und dabei so jittert, daß man deren Takt nicht für den USB verwenden kann? W.S.
temp schrieb: > Ralph S. schrieb: >> Nur um es klar auszudrücken: mbed wird auch eine Menge Power schlucken, >> weil einiges im Framework stecken bleibt. > > Das ist auch eine sehr gewagte Aussage. Hast du mal an Beispielen > gemessen von was wir hier sprechen? ... dann mach mal einen GPIO Zugriff über mbed ... und einen über BSSR (egal ob die Register händisch gesetzt hast, oder mit libopencm3 oder mit der StdPeriphLib ), schalte den dann ein und aus und seh dir das Ergebnis auf dem Scope an... temp schrieb: >> Wirklicher Nachteil hier ist >> dann allerdings, dass man ONLINE programmiert (in einem Webfenster) mit >> sehr eingeschränkten Möglichkeiten. > > Das kann man machen, muss es aber nicht. mbed genauso wie Arduino kann > man auch komplett mit allen Qellen in jeder IDE seiner Wahl benutzen und > debuggen. Dazu darf man aber nur nicht ganz auf den Kopf gefallen sein. Ich habe nichts anderes behauptet: Ralph S. schrieb: > Wer das Onlineprogrammieren nicht mag, kann sich ein in mbed angelegtes > Projekt nach arm-none-eabi-gcc konvertieren lassen und dieses mittels > Editor und Makefile weiter bearbeiten. Ich hätte wohl dazu schreiben sollen, dass dieses exportierte Projekt dann OFFLINE weiter bearbeitet werden kann. Natürlich kann mbed auch für andere Programmierplattformen Exporte erstellen.
Moby A. schrieb im Beitrag #4674153: > beim Umstieg und Umlernen und Umgang mit mehr Komplexität, die man bei > gegebenen Apps (mit AVR) vielleicht nicht haben bräuchte Es ist genau umgekehrt: AVR ist sooo kompliziert. Wir machen eigentlich alle Designs mit 8051 oder LPC ARM und da funktioniert alles einfach. Jetzt kam aber ein altes Design mit ATmega16 hoch und die Firmware sollte geändert werden, dafür wurde unser einziges mkII aus dem Schrank geholt und abgestaubt. Nach Erstkontakt mit Atmel Studio und dem Datenblatt hat der der es machen sollte aufgegeben und ist mit der Arduino IDE angerückt. Jetzt läuft es einigermaßen, aber z.B. die Umschaltung vom internen Oszillator auf den 8 MHz Quarz haben wir bisher nicht hinbekommen. Jetzt soll ernsthaft der ATmega16 durch einen 8051 ersetzt werden damit Ruhe ist. Ist aber schwierig, da es ein QFP-44 ist und aktuelle 8051 gibt es nur als QFP-32 oder QFP-48
Oooooh, wie soll ich nur Arduino und STM32 unter einen Hut bringen ? Muss ich mich jetzt total umgewöhnen ? der Wolperdinger: http://www.arduino.org/products/boards/arduino-star-otto zu teuer ? https://developer.mbed.org/platforms/ST-Nucleo-F446RE/ zu wenige Pins ? https://developer.mbed.org/platforms/ST-Nucleo-F746ZG/ keine kostenlose IDE wie Arduino ? http://www.openstm32.org/User+Guide zu kompliziert ein Projekt zu initialisieren ? http://www.st.com/content/st_com/en/products/development-tools/software-development-tools/stm32-software-development-tools/stm32-configurators-and-code-generators/stm32cubemx.html Das einzige Hindernis ist, mal was neues zu lernen. Vor dem Erfolg haben die Götter den Schweiß gesetzt. Gruß, dasrotemopped.
> die Umschaltung vom internen Oszillator auf den 8 MHz Quarz > haben wir bisher nicht hinbekommen Habt ihr keinen Techniker im Unternehmen?
Meine Erfahrung ist, dass ich die STM32 sehr ordentliche Controller sind (STM32F103). Leider habe ich den Fehler gemacht, mit dieser unsäglichen HAL anzufangen, und mir passenden Code per Cubemx generieren lassen. Es läuft zwar das meiste auf Anhieb, aber die Performance ist echt beschissen. Vorher war auf der Platine ein Atmel 644, der Zuwachs in der Geschwindigkeit war kleiner als erwartet, und das liegt v.a. am HAL. IO Zugriffe werden zur Lauftzeit ausgewertet, gefühlte 10000 Flags in den ISR geprüft. Sobald du also irgendwas brauchst, wo die zeitlichen Anforderungen kritisch sind, kannst du die HAL über Bord werfen und musst zwangsläufig von Hand coden. Dann musst du dich aber zwangläufig tiefer mit dem Controller auseinandersetzen, und dann ist es eigentlich wiederum egal ob du von Atmel auf NXP, STM32, PIC32, MPC's oder was auch immer wechselst. Wenn du vom Arduino kommst, dann kannst du in Punkto Geschwindigkeit kaum Anforderungen haben, demnach wird der zu ziemlich jeder gammlige STM32 die Forderung nach mehr IOs, Geschwindigkeit und v.a. mehr Speicher spielend erfüllen.
W.S. schrieb: > Willst du in irgend einer Szene z.B. Arduino vor anderen glänzen und > dürstest nach Lob? Nein das nicht, dann eher mit dem fertigen Projekt, statt den "innereien" > Willst du irgendwelche tatsächlichen Dinge schaffen, also irgend etwas > mit anschließendem echten Gebrauchswert? Ja, zum einen etwas was gut "nachbaubar" ist, zum anderen setze ich Arduino aktuell auch geschäftlich ein. Gerad für kleinere, nicht dauerhafte Aufgaben eignet sich das super und ist erst noch günstig. (z.B. Event-Logger, Impulsgeber usw) > Willst du was lernen, um in einem einschlägigen Fach beruflich weiter zu > kommen? Nicht direkt, aber uC Programmieren schaded in der Elektronik/IT Branche wohl fast nie > Willst du nur deine Freizeit mit etwas ausfüllen, das dir interessant > genug vorkommt? Ja, jedoch lieg dort der Fokus mehr auf dem "Endprodukt" der uC selbst ist für mich nicht der Hauptaspekt, eher eine "nötige Komponente" > Ich halte es damit ähnlich: Die Notwendigkeit, sich selbst etwas zur > Sache beizubringen und nicht zu erwarten, daß immer alles nur kurzweilig > und Spaß-Spaß-Spaß ist und einem von Lehrern irgendwo reingeschoben > wird, ist eine Art gesellschaftlicher Hygienemaßnahme, die dazu führt, > daß Leute, die eben nicht den inneren Drang in das betreffende > Fachgebiet haben, das Ganze langweilig oder stressig finden und sich was > Anderes suchen. Das ist GUT SO. Leicht geht es eben nur dann, wenn man > selbst sich Kenntnisse und Fertigkeiten angeeignet hat. Das > Schlaraffenland ist nur eine Mär. Klar muss es nicht immer Spass machen, aber wenn man bei einer Platform immer die 4 fache Fleissarbeit machen muss, während man sieht wie es auf anderen Platformen schneller und einfacher geht.
Stefan U. schrieb: >> die Umschaltung vom internen Oszillator auf den 8 MHz Quarz >> haben wir bisher nicht hinbekommen > > Habt ihr keinen Techniker im Unternehmen? Da sich hier im Forum gefühlt die Hälfte der Beiträge mit Fuse-Problemen beschäftigt, haben wir halt auch Bedenken, den ATmega16 dabei zu erledigen. Und auf Wiederbelebung mit CMOS Clock oder Auslöten haben wir keine Lust. Beitrag "avrdude schreibt keine Fuses bei ATmega8" Moby A. schrieb im Beitrag #4674271: > Und einfacher als das Takt-Setup jedes ARM Das wird hier immer verbreitet, aber bei den LPC ARM (und auch bei den aktuellen 8051) kann man während der Laufzeit die Oszillatoren einfach umschalten und wenn es mal schiefgegangen ist, kommt man mit dem ROM-Bootloader wieder rein. Beim ATSAMD21 (aus dem Arduino Zero) hat sich Atmel übrigens den ROM-Bootloader gespart, zudem trifft dort die Aussage "Takt-Setup schwierig" eindeutig zu.
Lothar schrieb: > Das wird hier immer verbreitet, aber bei den LPC ARM (und auch bei den > aktuellen 8051) kann man während der Laufzeit die Oszillatoren einfach > umschalten Das ist ja auch recht nützlich, wenn man je nach Betriebszustand mal mehr, mal weniger Rechenkraft braucht. Außerdem kann man auch das voltage scaling je nach Taktfrequenz rauf- oder runterdrehen, um den Energieverbrauch zu optimieren. > und wenn es mal schiefgegangen ist Dann hat man normalerweise immer noch den HSI, welchen man sogar als Input für die PLL nutzen kann. Abgesehen davon, daß der HSI ungenauer als der HSE ist, läuft die Anwendung aber dann trotzdem noch weiter. Man muß halt das Anwerfen des HSE mit Kontrolle in einer Warteschleife mit Timeout machen.
Moby A. schrieb im Beitrag #4674271: > Und einfacher > als das Takt-Setup jedes ARM. Aber gut, beim Asm-Programmer steht nichts > zwischen sich und der Hardware und er programmiert ohne Umwege ;-) Wenn Deine C-Kenntnisse dermaßen schlecht sind, daß Du schon an ein paar volatile Adreßdefinitionen samt Bitmasken scheiterst, mit denen man üblicherweise die Register betut, dann ist das sicherlich bemerkenswert, aber eher nichts, worauf Du stolz sein kannst. ^^ Ich sehe auch nicht, wo das Takt-Setup z.B. bei STM32 kompliziert wäre. Das Datenblatt sagt einem doch, welche Register welche Adressen haben und welche Registerbits was bedeuten.
Moby A. schrieb im Beitrag #4674883: > Bietet 8-Bit XMega auch Und wann kam der letzte neue XMega raus? Der neueste 8051 die EFM8 Laser Bee kam Anfang 2016 raus und dagegen sehen alle XMega sehr alt aus. Niemand nimmt XMega für neue Designs. Abgesehen davon sind die XMega kompliziert :-)
Moby A. schrieb im Beitrag #4674933: > Ich hab nichts gegen die 8051er Das läßt sich gleich ändern :-) ATXMEGAAU Datenblatt 340 Seiten EFM8LB Datenblatt+Manual 70+390=460 Seiten also wie bei ARM. Zudem wird für EFM8 8051 dieselbe Toolchain wie für EFM32 ARM genutzt :-) Ansonsten bieten die EFM8 analoge und digitale Peripherie, die es aktuell nirgends anders gibt. Und das zu einem unschlagbaren Preis. Hier der faire Vergleich ATXMEGA64AU und EFM8LB12F64 Preis bei Mouser: 5,57 / 1,76 Flash: 64k RAM: 4k CPU: 32 MHz / 72 MHz ADC: 12-Bit / 14-Bit DAC: 12-Bit 2x / 4x PWM: AWeX 11-Bit nur über Timer / PCA 16-Bit integrierte CPLD-Blöcke: - / 4x Haupt-Einsatzbereich sind optische Module wo vorher der DS4830 8051 für 4,95 genommen wurde.
Moby A. schrieb im Beitrag #4674883:
> Komplizierter als bei AVR ;-)
Nutzt Du denn überhaupt mal dynamische Taktanpassung im Betrieb, je
nachdem, was die Anwendung gerade tun soll?
Moby A. schrieb im Beitrag #4675095: > der Untergang des AVR Universums ansteht Dachte der steht an :-) Beitrag "ATMEL (Microchip) erhöht die Preise" > ARM-Modernisierung des Unterbaus Wie gesagt, Arduino hat sich ja für den ATSAMD21 als offiziellen ATmega328 Nachfolger entschieden: der ARM mit der ungünstigsten Peripherie überhaupt, "5V-tolerante" Pins aber 5.1V gibt den Rest, und ein M0 statt wenigstens ein M3, wäre nicht teurer gewesen, aber deutlich flotter.
Lothar schrieb: > Wie gesagt, Arduino hat sich ja für den ATSAMD21 als offiziellen > ATmega328 Nachfolger entschieden: der ARM mit der ungünstigsten > Peripherie überhaupt, "5V-tolerante" Pins aber 5.1V gibt den Rest, und > ein M0 statt wenigstens ein M3, wäre nicht teurer gewesen, aber deutlich > flotter. Wenn Du wss flotteres suchst dann gibt es den arduino due mit dem sam3x. Gibt sogar schon billigere Clones wie von Mikroelektronika http://www.mikroe.com/flip-n-click/
Moby A. schrieb im Beitrag #4675095: > Was aber letztlich zählt ist das Gesamtpaket In diesem Projekt wurde auch lange am AVR festgehalten, bis es nicht mehr ging, und zuerst auf C8051 umgestiegen wurde, und jetzt eben EFM8: http://fpv-racer.net/blheli-s-firmware-for-busybee-esc-aikon-sefm-30a-dys-xs20a-dys-xs30a/ http://dronehitech.com/ztw-flash-30a-blheli_s-esc/
Stefan schrieb: > Wenn Du wss flotteres suchst dann gibt es den arduino due mit dem sam3x Der wurde inzwischen offiziell abgekündigt (und von Anfang an nicht wirklich gut unterstützt): https://www.arduino.cc/en/Main/ArduinoBoardDue Zudem ist der SAM3X8E auch wieder der M3 mit der ungünstigsten und langsamsten Peripherie überhaupt, im Vergleich zu NXP, STM32, EFM32
Lothar schrieb: > Zudem ist der SAM3X8E auch wieder der M3 mit der ungünstigsten und > langsamsten Peripherie überhaupt, im Vergleich zu NXP, STM32, EFM32 ok ich orientiere mich ja nicht so in der Arduino Welt, nutze eigentlich nur die HW, entwickelt wird normal unter Atmel Studio 7 und über langsame Peripherie kann ich mich nicht beklagen, die Performance reicht völlig. ich habe den SAM3X genommen da es damals der erste Cortex war mit integriertem Highspeed USB onchip PHY und ETH MAC.
>der Wolperdinger: >http://www.arduino.org/products/boards/arduino-star-otto Interessantes Teil, wenn auch der Name etwas komisch ist. Ich denke bei "Otto" an Otto Walkes und nicht die italienische 8. Schade nur, dass man nirgends einen Preis und Lieferzeit erfahren kann. So, und hier noch die Story hinter Wiring ( der hinter Arduino versteckten Abstraktionsschicht ). Sehr lesenswert: http://arduinohistory.github.io/
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.