In den September-News von ST ist ein Artikel über einen neuen (?) 8pin MCU. http://www.st.com/en/microcontrollers/stm8s001j3.html?ecmp=tt5693_gl_enews_sep2017 8kB Flash - 1kB Ram - 128B EEprom - 3V...5,5V - SO8 Gehaeuse Nachdem ich AN5047 gelesen hatte, hatte meine anfaengliche Begeisterung doch einen Daempfer: Die Entscheidung, nRST nicht herauszuführen, hat doch so etliche Stolpersteine hervorgebracht. https://my.st.com/resource/en/application_note/dm00405517.pdf Weitere Lektüre: https://hackaday.io/project/27250-mcu-how-tos-reviews-rants/log/66992-stm8s001j3-the-good-the-bad-and-the-ugly Aber irgendwie hat dieser MCU schon einen Reiz, dem ich mich nicht entziehen kann. Werde mal 10 Stk. bei Digikey bestellen.
:
Bearbeitet durch User
Ja, das fehlende nRST und die vielen Funktionen, die auf de SWIM-Pin liegen machen es leicht, den Chip durch Programmierfehler unbenutzbar zu machen. Beim Schreiben der Tutorials http://www.colecovision.eu/stm8/STM8S001J3%20Reference%20LED.shtml und http://www.colecovision.eu/stm8/STM8S001J3%20Reference%20Serial.shtml habe ich auch ein paar Chips verbraucht. Philipp
Nur 7 pins, dank des Spannungsreglers? Nun ja, bei einigen Anwendungen reichen auch 4 I/Os. Ich warte dann mal auf die <$1.00 Boards mit diesem MCU aus China...
Tim . schrieb: > Ich warte dann mal auf die <$1.00 Boards mit diesem MCU aus China... Die "großen" STM8S103F3P6 gibt es doch jetzt schon als Board für 50 Cent inkl. Versand aus China: https://www.aliexpress.com/item/STM8S103F3P6-ARM-STM8-Minimum-System-Development-Board-Module/32525882811.html Die STM8S003F3P6 im TSSOP20-Gehäuse gibt es beim Ali auch jetzt schon für 20 Cent/St. im 10er-Pack: https://www.aliexpress.com/item/Free-shipping-10pcs-STM8S003F3P6-Value-line-16-MHz-STM8S-8-bit-MCU-STM8S003F3P6TR/32399834476.html Die kleineren SO-8 dürften aber trotzdem interessant sein, wenn man wirklich nur sehr wenige Pins braucht und das noch von Hand zusammenlöten will. Außerdem will man ja (gerade für kommerzielle Projekte) nicht unbedingt seine ICs beim Ali bestellen. Ich bin trotzdem mal gespannt für welchen Preis die Teile dann beim freundlichen Chinesen zu haben sein werden. Herzlichen Dank übrigens an Philipp für die Arbeit am SDCC. Ohne den SDCC-Support wäre das Teil für mich nichtmal ansatzweise von Interesse.
Kaufen die Chinesen so viele von den uC bei ST dass sie diese sehr günstig bekommen ?
Christopher J. schrieb: > Herzlichen Dank übrigens an Philipp für die Arbeit am SDCC. Ohne den > SDCC-Support wäre das Teil für mich nichtmal ansatzweise von Interesse. Ncht gegen den SDCC (ein alter Bekannter ;) aber das ist Dir auch bekannt? http://www.cosmic-software.com/download.php Cosmic für STM8 komplett frei & (angeblich) ohne Limits. /Regards
Andreas H. schrieb: > Christopher J. schrieb: >> Herzlichen Dank übrigens an Philipp für die Arbeit am SDCC. Ohne den >> SDCC-Support wäre das Teil für mich nichtmal ansatzweise von Interesse. > > Ncht gegen den SDCC (ein alter Bekannter ;) aber das ist Dir auch > bekannt? > > http://www.cosmic-software.com/download.php > > Cosmic für STM8 komplett frei & (angeblich) ohne Limits. > > /Regards Vor gut einem Jahr habe ich die damaligen Releases der C-Compiler für STM8 verglichen: http://www.colecovision.eu/stm8/compilers.shtml Ganz unten auf der Seite ist auch nochmal eine zusammenfassende Übersichtstabelle. Philipp P.S.: Wenn man den den aktuellen Stand (bei SDCC dann Snapshots, da es seither kein weiteres Release gab) betrachtet, hat SDCC seinen Vorsprung bei der Standardkompatiblität weiter ausgebaut und hat bei der Geschwindigkeit des erzeugten Code alle anderen Compiler überholt. Bei der Codegröße gab es dagegen nur kleinere Fortschritte, da ist SDCC zusammen mit IAR weiterhin das Schlußlicht.
Andreas H. schrieb: > Ncht gegen den SDCC (ein alter Bekannter ;) aber das ist Dir auch > bekannt? > > http://www.cosmic-software.com/download.php > > Cosmic für STM8 komplett frei & (angeblich) ohne Limits. Jein, also das es den Cosmic-Compiler gibt wusste ich aber da er nur Windows-only erhältlich ist, habe ich mir den gar nicht näher angeschaut. Eventuell läuft der auch unter Wine aber die Schmerzen wollte ich mir ersparen. Eine virtuelle Maschine wäre mir zu kompliziert und ein "richtiges" Windows würde mir den Spaß an der Sache wohl komplett verderben. Ich weiß natürlich, dass das einige Leute genau anders herum sehen. Für mich war der STM8 bisher reine Spielerei und angesichts der absurd niedrigen Preise für Cortex-M, z.B. STM32F030 wird er das wohl auch bleiben. Interessant finde ich den STM8 weil man den per ST-Link prima flashen und - vor allem - debuggen kann. Das ist leider bei den AVR-Boards wie Arduino-Nano und Co. deutlich schwieriger und noch dazu sind die Debugger deutlich teurer. Philipp Klaus K. schrieb: > Vor gut einem Jahr habe ich die damaligen Releases der C-Compiler für > STM8 verglichen: > > http://www.colecovision.eu/stm8/compilers.shtml > > Ganz unten auf der Seite ist auch nochmal eine zusammenfassende > Übersichtstabelle. Das hatte ich auch schon gesehen und bin wirklich positiv überrascht. Echt gute Arbeit die ihr da gemacht habt. Philipp Klaus K. schrieb: > P.S.: Wenn man den den aktuellen Stand (bei SDCC dann Snapshots, da es > seither kein weiteres Release gab) betrachtet, hat SDCC seinen Vorsprung > bei der Standardkompatiblität weiter ausgebaut und hat bei der > Geschwindigkeit des erzeugten Code alle anderen Compiler überholt. Bei > der Codegröße gab es dagegen nur kleinere Fortschritte, da ist SDCC > zusammen mit IAR weiterhin das Schlußlicht. A propos Release: Gibt es schon Pläne, wann das nächste Release kommt? Es geht mir da gar nicht unbedingt um Geschwindigkeit, sondern eher um Funktionalität, wie z.B. den Fix für die Dependency-Erstellung mit -MD. Ich habe auch mal kurz einen Blick ins Changelog geworfen und gesehen, dass der eine oder andere Bug behoben wurde, was ich natürlich ebenso begrüße, auch wenn ich bisher keine Probleme mit dem SDCC hatte. Momentan nutze ich den SDCC mit den Patches von https://stm8-binutils-gdb.sourceforge.io/ und muss sagen, dass das mit dem GDB echt gut klappt. Ich weiß nicht ob der Autor sich mal bei euch gemeldet hat aber es wäre echt schön wenn das im Upstream landen würde. Die "Qualität" der Patches kann ich absolut nicht beurteilen aber wie gesagt es funktioniert bisher alles bestens und damit meine ich das komplette Paket aus SDCC, OpenOCD und GDB.
Christopher J. schrieb: > Momentan nutze ich den SDCC mit den Patches von > https://stm8-binutils-gdb.sourceforge.io/ und muss sagen, dass das mit > dem GDB echt gut klappt. Ich weiß nicht ob der Autor sich mal bei euch > gemeldet hat aber es wäre echt schön wenn das im Upstream landen würde. Die patches aufhttps://stm8-binutils-gdb.sourceforge.io/ verwenden einen zusätzlichen framepointer im RAM für --debug. Das sollte sich aber anders eleganter lösen lassen. https://sourceforge.net/p/sdcc/mailman/sdcc-devel/thread/37d1091a-a0d4-5b72-3609-8c0ef0197f6a%40spth.de/ Ich habe 'mal ein Ticket auf Sourceforge auf Seite von stm8 binutils-gdb dazu angelegt: https://sourceforge.net/p/stm8-binutils-gdb/tickets/3/ Auch ansonsten müssten die Patches für SDCC noch etwas aufgeräumt werden, da sie Teilweise die Formatierung des Codes ändern, an Stellen an denen sich die Funktionalität nicht ändert. Philipp
Philipp Klaus K. schrieb: > ansonsten müssten die Patches für SDCC noch etwas aufgeräumt > werden, da sie Teilweise die Formatierung des Codes ändern, an Stellen > an denen sich die Funktionalität nicht ändert. Ha! Das ist mir auch aufgefallen (ich habe mal kurz über die Patches geschaut, ob es prinzipielle Gründe gäbe, warum sie nicht auf eine neuere Version von sdcc passen sollten). Insbesondere fügen sie Code auch hinzu, der auskommentiert ist. Ziemlich schlampig. Leider :(
Christopher J. schrieb: > A propos Release: Gibt es schon Pläne, wann das nächste Release kommt? Wir hatten 'mal vor, ein 3.7.0 Release im Sommer zu machen, aber daraus ist nichts geworden. Das ob, wann und wie weiterer Releases ist zur Zeit eher offen. Philipp
Christopher J. schrieb: > Momentan nutze ich den SDCC mit den Patches von > https://stm8-binutils-gdb.sourceforge.io/ und muss sagen, dass das mit > dem GDB echt gut klappt. Ich weiß nicht ob der Autor sich mal bei euch > gemeldet hat aber es wäre echt schön wenn das im Upstream landen würde. Wir (sowohl der Autor der Patches dort als auch ich) arbeiten seit ein paar Tagen daran. Wie es aussieht, wird das Debugging in SDCC 3.7.0 noch besser funktionieren als in 3.6.0+patches. Einiges ist schon im svn, aber es fehlen noch ein paar Sachen, insbesondere für lokale Variablen, die teils in Registern, teils auf dem Stack liegen. Der weitere Fortschritt sollte unter https://sourceforge.net/p/sdcc/feature-requests/539/ verfolgbar sein. Philipp
Philipp Klaus K. schrieb: > machen es leicht, den Chip durch Programmierfehler > unbenutzbar zu machen. > habe ich auch ein paar Chips verbraucht Ach? Wie das? Ich dachte Christopher J. schrieb: > prima flashen und - vor allem - debuggen kann. Das ist > leider bei den AVR-Boards wie Arduino-Nano und Co. deutlich schwieriger Mit Verlaub- deutlich schwieriger, das ist doch Quatsch :(
Philipp Klaus K. schrieb: > Wir (sowohl der Autor der Patches dort als auch ich) arbeiten seit ein > paar Tagen daran. Wie es aussieht, wird das Debugging in SDCC 3.7.0 noch > besser funktionieren als in 3.6.0+patches. Einiges ist schon im svn, > aber es fehlen noch ein paar Sachen, insbesondere für lokale Variablen, > die teils in Registern, teils auf dem Stack liegen. Der weitere > Fortschritt sollte unter > https://sourceforge.net/p/sdcc/feature-requests/539/ verfolgbar sein. > > Philipp Sehr coole Sache. Ich schließe mal daraus, das es dann auch ein 3.7.0 Release geben wird. Gerhart schrieb: > Philipp Klaus K. schrieb: >> machen es leicht, den Chip durch Programmierfehler unbenutzbar zu >> machen. >> habe ich auch ein paar Chips verbraucht > > Ach? Wie das? Ich dachte > > Christopher J. schrieb: >> prima flashen und - vor allem - debuggen kann. Das ist leider bei den >> AVR-Boards wie Arduino-Nano und Co. deutlich schwieriger > > Mit Verlaub- deutlich schwieriger, das ist doch Quatsch :( Die Aussage von Philipp war auf den 8-Pinner bezogen und der hat, im Gegensatz zu den STM8 ab TSSOP20, keinen dedizierten SWIM-Pin. Das gleiche Problem haben meiner Meinung nach die kleineren AVRs ohne JTAG, da man hier den Reset-Pin doppelt benutzt und sobald da ein Taster mit Kondensator dran hängt ist halt nix mehr mit Debugging.
Christopher J. schrieb: > da man hier den Reset-Pin doppelt benutzt und sobald Mehrfachbelegung, gerade bei Programmierpins, sollte daher nur in Ausnahmefällen infrage kommen. Der/die werden in einem sauberen Design immer freigehalten! Da wir hier schon bei neuen Produkten (und alten Programmierschnittstellen) sind möchte ich auch mal an die neue UPDI-Schnittstelle aktueller Microchip-MCs erinnern. Ein Pin langt nämlich inzwischen herstellerübergreifend und nach Stand der Technik für den ganzen Service...
Gerhart schrieb: > Mehrfachbelegung, gerade bei Programmierpins, sollte daher nur in > Ausnahmefällen infrage kommen. Der/die werden in einem sauberen Design > immer freigehalten! Da wir hier schon bei neuen Produkten (und alten > Programmierschnittstellen) sind möchte ich auch mal an die neue > UPDI-Schnittstelle aktueller Microchip-MCs erinnern. Ein Pin langt > nämlich inzwischen herstellerübergreifend und nach Stand der Technik für > den ganzen Service... Naja, ein Chip mit 8 pins ist wohl so ein Ausnahmefall. Er hat ja auch nur einen Programmierpin, aber der ist halt auch noch mit anderen Funktionen belegt. Philipp
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.