Servus allerseits Wegen verschiedenen Faktoren musste ich etwas über den Tellerrand schauen und stiess bei meiner Suche auf die STM8-Serie. Ich war angenehm überrascht, wieviele Möglichkeiten in diesen MCUs stecken. Und vorallen für Leute, die sich bereits mit dem STM32 auskennen und hin und wieder in die StdLib einen Blick werfen, ist die Adaptionsphase sehr kurz. Zum Teil tragen die Flags sogar dieselben Namen. Ich brauchte gerade mal 2 Tage, bis ich ein kleines Projekt vom STM32 auf den STM8 portiert hatte. MfG
Was muss man bei den STM8 denn so in Debugger und Compiler investieren?
Wenn Du mit einem Discovery-Board anfaengst, ist der Debugger (ein ST-Link) onboard. Den kannst Du aber auch selbst als Debugger benutzen. Der ST-Link separat kostet glaube ich so um die 20 EUR. Als Compiler benutze ich z.Zt. den Iar-Kickstart. Kostet bis 8kB nichts. Edit: Ein Nachteil beim Ganzen ist, dass im Internet nicht sehr viele Quellen vorhanden sind. Man muss also selbst sehr oft hinter die Bücher :) und da war ich der Meinung, dass meine Kenntnisse mit STM32 mir sehr viel genutzt haben.
Der Preis war natürlich ein Argument. Aber nicht ausschlaggebend. Ich brauchte vorallem 16 ADC Eingaenge und ein SPI das nicht buggy war. Der SPI von STM32F0 ist ziemlich verseucht. Der STM32L151 bzw. 152 waeren möglich gewesen. Aber um ganz ehrlich zu sein: ich wollte wieder einmal mit einer Steinschleuder auf Spatzen schiessen. Und ich muss eingestehen: der STM8 macht Spass!
Ich hab' mir das STM8L-Discovery Board auch gerade besorgt, weil ich für einen Sensor etwas kleines, stromsparendes mit ADC brauchte. Ich finde den Chip auch toll, aber ich wollte wg. der Größe die Chips im TSSOP20-Gehäuse haben, die kann man in Deutschland allerdings nirgendwo kaufen...
Farnell hat sie im Angebot. Vom STM8L101F2P6 gibts nur noch 10 Stk., aber vom STM8S003F3P6 fast 3.000 Stk. ( 0,47 EUR @ 100 Stk.)
Ja, das ist richtig, aber die mit 12-bit ADC nicht (STM8L051, STM8L151).
Mit ADC hat Silabs einiges: http://www.silabs.com/products/mcu/mixed-signalmcu/Pages/C8051F35x.aspx http://de.farnell.com/silicon-laboratories/c8051f353-gm/mcu-768b-ram-smd-mlp-28-8051/dp/1291528
Ich habe mir STM8L151 bei Mouser gekauft, ging problemlos. Sehr schön finde ich die Libs dazu, man kommt recht schnell zum Ergebnis. - Entwicklungsumgebung kostenlos - Debuggen mit vielen Breakpoints möglich - sehr günsiger Debugger (Discovery) - Programmierung über 3 Leitungen - sehr viel Peripherie Ebenfalls erwähnenswert ist der interne Takt mit +/- 1% bei Consumertemperaturen. Der Controller startet immer mit internen 2MHz => kein "zerfusen" möglich
>Und ich muss eingestehen: der STM8 macht Spass!
Kann sein, ist sehr schnell (macht vieles in 1 Takt) und ist extrem
günstig. (glaube ab ca 0,20eu !)
Aber die Port-Belegungen sind schlecht! Es gibt so gut wie keine
zusammenhängende Ports mit >=4 Bits! Auch sind die meisten nur als
Lowdrive (keine 20mA) bzw nur für 2 MHz -Out benutzbar.
Also mal schnell ein paar Bits paral. ausgeben, geht nicht! (Was die
sich dabei gedacht haben???)
Und (falls es jemanden interssant) DIL gibts auch so gut wie keine.
(viell. weil die Serie ja zieml neu ist)
MCUA schrieb: > Und (falls es jemanden interssant) DIL gibts auch so gut wie keine. Das wird in Zukunft vermutlich immer öfter so sein. HT ist einfach zu teuer und aufwendig für Chiphersteller und -kunden.
Der stm8 wird inzwischen auch vom normalen sdcc (http://sdcc.sourceforge.net/) unterstützt. Vermutlich wird stm8 beim nächsten Release (3.4.0) eine der offiziell unterstützen Architekturen sein. Philipp
Wer den alten 6502 oder 6800 kannte, wird vom STM8 begeistert sein. Nur die Peripherie ist halt etwas komplexer geworden. Und IAR wird für grössere Projekte auch gebraucht.
Es ist garnicht so schwer, sich eine brauchbare Entwicklungsumgebung dafür zu bauen. Habe hier folgendes innerhalb von zwei Abenden unter Windows7 zum Laufen bekommen: - GNU-Binaries für Windows (bash,make,rm,cp,mv usw.) - sdcc (snapshot binary) - Eclipse C/C++ inkl. Workspace zur Verwendung von GNU-Binaries und sdcc - stm8s toolchain mit Anpassungen für sdcc - Toolchain für STM8S als statische Lib Die größten Probleme waren: - Die Toolchain von STM ist nur für die beiden kommerziellen Compiler vorgesehen und verweigert den Betrieb mit sdcc. Hier ist etwas Handarbeit gefragt. - sdcc verwendet eigene Konstrukte, die von denen der kommerziellen Compiler abweichen, z.B. __interrupt(i). Bestehender Beispielcode muss oft umgeschrieben werden. Bisher läuft alles wunderbar auf dem STM8S Discovery für 8 Tacken. Beide Daumen hoch! Für Kleinprojekte werde ich wohl kaum noch ATTINYs kaufen. Und wenn ein Projekt endgültig installiert ist, kann der mitgelieferte Programmer einfach abgebrochen werden, dann liegt für lau ein weiterer STM32 im Schrank. Nachtrag: Noch ein Abend drauf, und jetzt machen hier fünf WS2812 'ne prima Moodlamp.
Das klingt ja interessant... ein Tutorial dafür wäre eine feine Sache. Mit Toolchain ist hier nur SPL gemeint, oder? Wie kommt das Programm in einer solchen Konfiguration in den STM8? Kann das Programmiertool integriert werden? Lohnt sich Eclipse wirklich, oder kann man sdcc auch in eine einfachere Umgebung integrieren (z.B. Programmers Notepad)?
- Tutorial: Vielleicht während des nächsten Urlaubs... - Toolchain: Ja, es ist die standard peripheral library, aus einem der Beispielprogramme extrahiert. Für jeweils eine Controllerklasse empfehle ich definitiv das Erstellen einer eigenen statischen Lib, da das ständige Einbinden der benötigten C-Quelldateien zum jeweiligen Projekt doch auf Dauer etwas sperrig ist. - Flashen: Im Augenblick noch mit dem Tool von STM. Experimente mit flashen per Kommandozeile stehen bei mir noch aus. Es funktioniert aber auch so schon ganz brauchbar. - Eclipse Es geht natürlich auch wunderbar ohne Eclipse. Allerdings würde ich schon irgendeine IDE über den make-Aufruf legen; Das Springen vom gefundenen Fehler zur korrekten Zeile im Texteditor ist doch recht angenehm. Eine Kombination aus notepad++/pspad/sublimetxt/emacs/vi/butterflies und make sollte aber kein Problem sein; Eclipse macht letzlich das gleiche. Es ist auch zu bedenken, dass die Syntaxanalyse von Eclipse CDT die Erweiterungen von sdcc nicht kennt. Die Anzeige solcher Fehler im Editor sollte also ausgeschaltet werden. Das ganze ist halt nicht so wasserdicht wie andere Eclipse-Umgebungen oder gar Visual Studio oder XCode. Aber hey, es geht um Microcontroller, nicht um fette Apps. So ein bisschen darf das noch nach Technik riechen, oder? Unter Linux funktioniert das Flashtool von STM nicht, deshalb habe ich das völlig ungeekhaft unter Windows eingerichtet. Man möge mir verzeihen.
OK, hier ist eine Anleitung nicht für Eclipse, sondern Code::Blocks: Beitrag "STM8S Discovery, Code::Blocks und SDCC"
Das stm8flash von Valentin ist inzwischen ganz brauchbar. Ich verwendete es schon vor Monaten mit dem stlink, und seit ein paar Tagen funktioniert es auch mit dem stlinkv2. Philipp
Da präzisiere ich mich denn mal, da mein Blog jetzt online gegangen ist. Hier steht ziemlich genau, wie Code::Blocks mit SDCC und der Toolchain von STM verknüpft wird. Alles kostenlos und uncrippled; Fröhliches Basteln! http://blog.podstuff.de/de/codeblocks-fuer-stm8s-discovery-einrichten/
Bitte 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.