Hallo, nachdem ich gerade geistig aus der Palmsonntagsmesse gekommen bin und es leider in diesem Forum nur sehr wenige Informationen zu Mikrocontrollern von ST Microelectronics gibt, möchte ich heute ein bisschen über den STM8 informieren, der seit gut einem Jahr erhältlich ist. Vielleicht wird sich ja der Eine oder Andere das Teil einmal genauer ansehen. Es handelt sich um eine modifizierte Harvard-Architektur (über Begriffe kann man bekanntlich streiten, "Harvard vs. von Neumann" artet ja öfters in einem Flamewar aus), der Prozessor hat getrennte Daten- und Instruktionsbusse, verfügt aus Programmierer-Sicht jedoch über einen gemeinsamen, linearen Speicher. Der Adressraum ist mit einer Größe von 16 MByte üppig und zukunftssicher. Der Stackpointer ist 16 Bit breit, Probleme wegen eines zu flachen Stacks dürften beim STM8 also kaum auftreten. Eine 3-stufige Pipeline sorgt für schnelle Ausführungszeiten. Derzeit sind Derivate mit 6kB RAM und 128kB Flash erhältlich. Als besonderes Schmankerl enthalten diese Controller zusätzlich sogar echtes EEPROM, mit einer größe von (derzeit) bis zu 2 kByte. Drei Linien sind erhältlich: STM8S - die Standardvariante, STM8L - Low-Power-Variante mit Eingangsspannungen hinunter bis zu 1,65V und STM8A - die robuste Automotive-Version. Die maximale Taktfrequenz beträgt derzeit 24MHz. Die verwendete 130nm-Technologie macht den Controller zu einem der sparsamsten 8-Bitter. Das Instruction Set verfügt über zwanzig Adressierungsmodi, die durchschnittliche Größe einer Anweisung beträgt 2 Bytes. Multiplikation und Division sind ebenso verfügbar wie Bitmanipulationen. Nested Interrupts sind möglich, ebenso ist DMA verfügbar. Neben den üblichen Peripherien (SPI, I²C, USART,...) sei hier noch auf den integrierten CAN-Controller verwiesen, der Kosten sparen hilft. DER ADC bietet 10 oder 12 Bit Auflösung, Timer sind 8 oder 16-bittig mit der Möglichkeit der PWM-Ausgabe. Programmiert wird mittels einer Eindrahtverbindung, dem SWIM (Single Wire Interface Module). Ein Eval-Board, das so genannte STM8-Discovery - (welches sich auch als SWIM-Programmiergerät für Eigenentwicklungen verwenden lässt) ist für unter zehn Euro erhältlich, z.ß. bei Watterott unter http://www.watterott.com/de/Boards-Kits/STM8-ST7 Gerne hätte ich noch mehr über den STM8 erzählt, ich bin jedoch um 1300 mit einem Freund zum chinesisch Essen verabredet. Vielleicht habe ich trotzdem jemand auf den geschmack gebracht, Iwan
Иван S. schrieb:
> nachdem ich gerade geistig aus der Palmsonntagsmesse gekommen bin
Sorry, natürlich kam ich nicht "geistig" aus der Messe sondern geistig
aufgefrischt.
Ich hab hier auch noch nen STM8S-Discovery von der Embedded-world rumliegen; leider sieht's mit ner linux-toolchain recht mau aus :(
Hi Iwan, vielen Dank für deinen interessanten und gut geschriebenen Beitrag zum STM8. Könntest Du vielleicht noch etwas zur Tool-Chain schreiben? Gibt es hier kostenlose Varianten, welche z.B. auf 4 kB Programmspeicher begrenzt sind. Ist man auf eine spezielle IDE angewiesen? Oder gibt es eine freie Tool-Chain, welche sich auch in Eclipse integrieren lässt? Welchen Vorteil dieses Controllers siehst du gegenüber dem ATxmega128a1, dem MPS430 oder einem Reneas Controller? Ist ST noch eigenständig, oder haben sie sich mit einem anderen Halbleiterhersteller zusammen geschlossen? Ich wünsche Dir noch einen schönen Sonntag und ich hoffe das chinesische Essen war gut. ;-) Viele Grüße, Sebastian
G4st schrieb: > leider sieht's mit ner linux-toolchain recht mau aus :( Stimmt, das sehe ich ebenfalls als großes Manko. Über den Betrieb der Windows-Tools für STM8 gibt es widersprüchliche Angaben. Nachdem was ich so ergurgelt habe funktionieren die Anwendungen jedoch unter VirtualBox. Sebastian B. schrieb: > vielen Dank für deinen interessanten und gut geschriebenen Beitrag zum > STM8. Danke für die Blumen, ich werde in näherer Zukunft auch einen Artikel zum STM8 hier im Wiki ausarbeiten, wenn ich 'mal Zeit habe. > Könntest Du vielleicht noch etwas zur Tool-Chain schreiben? > Gibt es hier kostenlose Varianten, welche z.B. auf 4 kB Programmspeicher > begrenzt sind. Ist man auf eine spezielle IDE angewiesen? Zum einen gibt es von Raisonance einen C-Compiler der in der freien Version auf 16k beschränkt ist. Von Raisonance gibt es dazu die IDE Ride. Daneben gibt es den Cosmic Compiler welcher ebenfalls auf 16k limitiert ist. Die dazugehörige IDE nennt sich IDEA. Sowohl Die Raisonnance-Tools als auch jene von Cosmic lassen sich in die IDE von ST, dem ST Visual Develop (STVD) einbinden. > Oder gibt es eine freie Tool-Chain, Ein freier C-Compiler ist mir leider nicht bekannt. > welche sich auch in Eclipse integrieren lässt? Zumindest der Cosmic-Compiler lässt sich, nachdem was ich so ergurgelt habe, in Eclipse einbinden. Möglicher Weise funktioniert das auch mit jenem von Raisonance. Generell kann ich nicht sehr viel zu diesem Thema sagen, da ich eigentlich nur den ST-Assembler verwende. Ich kann für Dich auch nichts ausprobieren, da ich hier mit einem alten Ersatzrechner unter Debilian unterwegs bin, da mein "normaler" Rechner kaputt geworden ist (siehe: Beitrag "Nie wieder ein Notebook von MSI" ) Schade finde ich jedenfalls, daß es keinen offenen Assembler gibt. Es wäre nämlich sehr schön, einen Assembler zu haben, der auf allen möglichen Architekturen läuft. Sicher, ein guter Programmierer nimmt das Datenblatt zum Instruction Set und programmiert sich den Assembler in zwei, drei Tagen selbst. Dazu fehlt mir leider das Können. > Welchen Vorteil dieses Controllers siehst du gegenüber dem ATxmega128a1, > dem MPS430 oder einem Reneas Controller? Bis auf den MSP430 kenne ich keinen der Genannten. Gegenüber dem MSP gefällt mir die Akkumulatorarchitektur des ST-Controllers besser. Der STM8 kann ausserdem dividieren. Den CAN-Controller und das echte EEPROM (hat der von Dir erwähnte ATMega anscheinend auch) habe ich ja schon im OP erwähnt :-). Vom Stromverbrauch sind beide in etwa gleich, beide benötigen ungefähr 150 uA/MHz. Für manche Anwender mag der erweiterte Temperaturbereich des STM8 den Ausschlag geben, denn so weit ich weiss gibt es vom MSP430 keine Automotive-Version. Zudem besitzen Beide ähnliche Großhandelspreise. Bei den Katalog-Distributoren scheint der STM8 gegenüber dem MSP430 etwas billiger zu sein. Beim MSP gibt es mehr Derivate, aber fairer Weise muß man auch sagen, daß der MSP um einiges älter ist. Auch ST bringt laufend neue Typen heraus, da darf man noch auf Vieles gespannt sein. Gerade der Vergleich MSP430 vs. STM8 ist also ziemlich schwierig. Leider habe ich hier kein funktionierendes Flash installiert, sodaß ich die parametrischen Suchen mancher Hersteller nicht benutzen kann. > Ist ST noch eigenständig, oder haben sie sich mit einem anderen > Halbleiterhersteller zusammen geschlossen? ST ist eigenständig und der größte europäische Halbleiterhersteller. Vor 1998 nannten sie sich SGS-Thomson, der Name könnte Dir (je nach Deinem Alter) noch ein Begriff sein. SGS-Thomson wiederum entstand Ende der 80er aus der italienischen SGS (Semiconductor General Society) Microelettronica und der französischen Thomson (bzw. der Halbleitersparte von Thomson). > Ich wünsche Dir noch einen schönen Sonntag Danke, ich wünsche Dir gleiches von ganzem Herzen. > und ich hoffe das chinesische Essen war gut. ;-) Ja, sehr gut. Wie immer habe ich beim All-U-Can-Eat wieder mächtig zugeschlagen. Für heute bin ich satt. Gruß, Iwan
> Schade finde ich jedenfalls, daß es keinen offenen Assembler gibt. Es > wäre nämlich sehr schön, einen Assembler zu haben, der auf allen > möglichen Architekturen läuft. Gibt es Arnolds-AS nicht mehr? Der hat doch auch mit Tabellen gearbeitet und sollte sich daher anpassen lassen. > Der STM8 kann ausserdem dividieren. Naja, wenn ein Prozessor das schon nicht koennte... > Zudem besitzen Beide ähnliche Großhandelspreise. Wieviel? Ich arbeite mich gerade in den R32C116 ein. Der liegt so bei 8-9Euro. Dafuer aber 50Mhz, 32Bit, 384k Flash, 40k Ram, 9xRS232/SPI/I2C, 15Timer, DMA, CRC, AD und DA, FLiesskommaheinheit usw usw... Einziger Nachteil, man braucht mindestens einen E8a. (E8 geht nicht) Singlewire mit E30 ist wohl fuer Bastler jenseits des finanzierbaren. Andererseits die Kisten haben ja soviele RS232 da merkt man den Verlust eines Uarts garnicht mehr. Olaf
Olaf schrieb: >> Schade finde ich jedenfalls, daß es keinen offenen Assembler gibt. > Gibt es Arnolds-AS nicht mehr? Der hat doch auch mit Tabellen gearbeitet > und sollte sich daher anpassen lassen. Den AS gibt es noch, allerdings hat er keinen Support für den STM8. Da er jedoch den ST7 kennt, wäre es wohl für einen erfahrenen Programmierer (also nicht für mich) sicher möglich, STM8-Support reinzuhacken. Allerdings hat Alfred Arnold wohl derzeit andere Prioritäten, das letzte Release stammt von 1999, die letzte Current von 2006. Ausserdem gibt es für AS keinen Linker :-( >> Der STM8 kann ausserdem dividieren. > Naja, wenn ein Prozessor das schon nicht koennte... AVR kann es nicht, ebensowenig wie MSP430 oder PIC (wenn ich recht informiert bin). >> Zudem besitzen Beide ähnliche Großhandelspreise. > Wieviel? Direkt beim Hersteller unter einem halben Euro für die kleineren Modelle, im Tausender. Bei den Katalogdistris (Farnell, DigiKey) je nach Flash so zwei bis drei Euro als Einzelstück. Echter Großhandel liegt irgendwo dazwischen schätze ich, da hab' ich aber keinen Zugriff. > Ich arbeite mich gerade in den R32C116 ein. Der liegt so bei 8-9Euro. Das ist auch ein ganz anderes Kaliber :-) > Dafuer aber 50Mhz, 32Bit, 384k Flash, 40k Ram, 9xRS232/SPI/I2C, 15Timer, > DMA, CRC, AD und DA, FLiesskommaheinheit usw usw... Wünsche ich Dir viel Spaß damit. Wär' mir persönlich zu komplex, ich bleib' in meiner kleinen, bescheidenen 8-Bit-Welt (auch auf die Gefahr hin, daß mich Herr Falk Brunner wieder als 'Elektronikautist' beschimpft). > Einziger Nachteil, man braucht mindestens einen E8a. (E8 geht nicht) > Singlewire mit E30 ist wohl fuer Bastler jenseits des finanzierbaren. Das ist beim STM8 wieder saubillig, single wire unter 10 Euro. > Andererseits die Kisten haben ja soviele RS232 da merkt man den Verlust > eines Uarts garnicht mehr. Auch wieder wahr ;-) > Olaf Iwan, mit grässlicher Auflösung arbeitend, da Monitor am Notebook hängt, und für den Monitor keine angenehme Auflösung durch die Notebook-Graphikkarte unterstützt wird. Der Ersatzrechner installiert seit eineinhalb Stunden Fedora 11 von einen 2-fach CD-Laufwerk...
@Olaf Kann es sein, dass Du Probleme mit UART6 hast? Oder ist Olaf K. ein anderer? :-)
> Kann es sein, dass Du Probleme mit UART6 hast?
Stimmt. Ich muss also praezisieren, alles am R32 ist gut, aber
der §$%"§$!"$"$ Uart6 bringt mich noch dazu auf dem Teil mit
einem grossen Hammer rumzuklopfen. ARGH!
Oder ich kneife die Pins fuer den Uart6 ab und tilge jede Seite
aus dem Datenblatt die von dem Uart6 handelt.
So, jetzt muss ich aber erstmal wieder an meinen Blutdruck denken
und einen Kamillentee trinken... :-)
Olaf
>...und einen Kamillentee trinken... Koch Dir besser gleich eine ganze Kanne :-) Es kann nämlich sein, dass Du alles richtig machst und das Teil dennoch nicht funktioniert. Ich weiß nicht, ob der R32C auch mit einem E10a betrieben werden kann. Mit den E8 hatte ich nie etwas erreichen können (bei SH + H8SX). Vielleicht macht ein E10a die Suche einfacher. Vielleicht ist dieser Link für Dich interessant: http://www.msc-toolguide.com/renesas/tool-family/rsk/renesas-starter-kit-plus-for-rx610.html Wenn da ein E10a dabei ist, wäre das ein guter Preis für Beides.
> Иван S. schrieb: > > nachdem ich gerade geistig aus der Palmsonntagsmesse gekommen bin > > Sorry, natürlich kam ich nicht "geistig" aus der Messe sondern geistig > aufgefrischt. **grins** ich kam immer sehr verschlafen aus der Kofi-Sonntags-Zwangsveranstaltung :-)
> Koch Dir besser gleich eine ganze Kanne :-) Oder ich gebe mich dem Alkohol hin. Seufz. > Es kann nämlich sein, dass Du alles richtig machst und das Teil > dennoch nicht funktioniert. Gelegentlich kam auch mir schon der Gedanke das der Prozessor einen Defekt im Uart6 haben koennte. Allerdings habe ich hier einen R32C116 und einen R32C118 die beide identisches Fehlverhalten aufweisen und man sollte die Fehler ja zuerstmal bei sich sich selber suchen, besonders natuerlich wenn man einen Prozessor noch nicht richtig kennt. Und die R32 haben ja auch genug Bits als das man da mal eins uebersehen koennte. > Ich weiß nicht, ob der R32C auch mit einem E10a betrieben werden kann. Nein. Nur E8a, E30 (bin ich zu arm fuer) und normaler RS232 Anschluss. Allerdings wird ein Debugger da auch nicht viel helfen. Irgendwas laeuft in der Statemachine falsch welche letzlich das I2C-Interface bildet, egal ob ich da was falsch mache oder ein Defekt vorliegt. Aber reinschauen kann ich da sowieso nicht und dokumentiert ist die auch nicht. Olaf
Иван S. schrieb: > Ich werde in näherer Zukunft auch einen Artikel > zum STM8 hier im Wiki ausarbeiten, wenn ich 'mal Zeit habe. Eine grobe Übersicht zum STM8 findet sich unter http://www.mikrocontroller.net/articles/STM8 Gruß, Iwan
Als assembler kann ich vasm empfehlen, den portiere ich auch gerade. Sollte schon möglich sein auch einen STM8 port zu erstellen.
Marius S. schrieb: > Als assembler kann ich vasm empfehlen, den portiere ich auch gerade. > Sollte schon möglich sein auch einen STM8 port zu erstellen. Möglich ist es bestimmt, nur übersteigt das meine bescheidenen kognitiven Fähigkeiten. Naja, immerhin hab' ich an ST selbst eine Anfrage gemacht, die uter Anderem auch das Thema des "unfreien" Assembler anschneidet. Mein Englisch ist zwar nicht besonders, trotzdem denke ich, das der FRED im STM8-Forum lesenswert sein könnte: https://my.st.com/public/STe2ecommunities/mcu/Lists/STM8/Flat.aspx?RootFolder=%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fSTM8%2fA%20few%20questions%20to%20ST%20%28about%20sampling%2c%20roadmap%2c%20assembler%20and%20parametric%20search%29&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009786738307FCB24DB76B09BF0FB5BB81&TopicsView=https%3A%2F%2Fmy.st.com%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2FSTM8%2FAllItems.aspx¤tviews=21 Iwan
Der STM8 hat einen rel. bescheidenen Registersatz, aber er ist verflixt schnell !!!! Etliche Mathe- u. Bit-Befehle (auch über 64k gesehen), gehen mit nur einem Takt !!! Da kann sich ein AVR (PIC sowiso) oder auch ein (R8C - auch M16C ) "warm anziehen". Selbst der R32C ist in machen Fällen langsamer (wenn man gleiche takt-f annimmt). (bsp.weise braucht dieser für ADD mem, reg (-->) auch 2 Takte)
Weil MCUA so schwer begeistert zu sein scheint (!!!!!!), habe ich mir 'mal die Datenblätter überschlägig angesehen: es haut mich nicht vom Hocker! Wieder 'mal eine CPU, bei der (fast) jedes Byte über den Accu laufen muß. Das hatten wir doch schon beim 6502 oder 8051. Vielleicht ist der Chip in 10000er Stückzahlen recht günstig, aber Können kann er nicht viel. Einen externen Bus hat er wohl auch nicht, mit seinen max. 80 Pins. Dann doch lieber 'nen AVR oder besser einen R32C :-)
Tropenhitze schrieb: > Wieder 'mal eine CPU, bei der (fast) jedes Byte über den Accu laufen > muß. Das hatten wir doch schon beim 6502 oder 8051. Das muß ja nicht heißen, das das schlechter ist. Mir persönlich gefallen Akkumulator-Architekturen jedenfalls recht gut. Ob das Register jetzt A heisst oder R0 ist doch eigentlich egal. Irgendwie scheinen manche Leute auf Akkumulatoren allergisch, ich kann mir jedoch nicht erklären warum. > Vielleicht ist der Chip in 10000er Stückzahlen recht günstig, Auch in Einzelstücken. Ausserdem gibt ein billiges Evalboard, das man auch als Programmieradapter benutzen kann, für unter 10 Euro. > aber Können kann er nicht viel. Was (ausser einem externen Speicherbus) fehlt Dir? Das Ding hat all' die üblichen Peripherien wie I2C, SPI, ADC... Ausserdem hat er CAN und kann dividieren. Und langsam ist er auch nicht. > Einen externen Bus hat er wohl auch nicht, mit seinen max. 80 Pins. Wozu auch bei einem 8-bit-Controller? Reichen Dir die 6k SRAM nicht? > Dann doch lieber 'nen AVR oder besser einen R32C :-) Jeder wie er will. Ich werde mir den STM8 jedenfalls noch länger genauer ansehen. Gruß, Iwan
@ Иван S. (ivan) >Das muß ja nicht heißen, das das schlechter ist. Mir persönlich gefallen >Akkumulator-Architekturen jedenfalls recht gut. Es gibt auch Leute, die hören lieber ne Drehorgel auf dem Jahrmarkt als ne CD ;-) MFG Falk
@ Иван S. >Ich kann für Dich auch nichts >ausprobieren, da ich hier mit einem alten Ersatzrechner unter Debilian >unterwegs bin, da mein "normaler" Rechner kaputt geworden ist (siehe: >Beitrag "Nie wieder ein Notebook von MSI" ) Ein Tipp bzgl. Laptop: Kauf Dir einen Dell. Der ist gleich teuer die die anderen, aber qualitativ viel besser und hat eine ordentliche Display-Auflösung. Ich selbst nutze seit vielen Jahren Dell und bin damit sehr zufrieden. Alle 2-3 Jahre kaufe ich mir aus Sicherheitsgründen eine neue Platte, reine Vorsichtsmaßnahme.
> 'mal die Datenblätter überschlägig angesehen: es haut mich > nicht vom Hocker! Mich hauen Geschwindigkeitsbetrachtungen sowieso nicht vom Hocker weil ein Controller fuer eine bestimte Aufgabe entweder immer schnell genug ist, oder aber so langsam das ein anderer Controller das nicht richten wird, man also besser ueber seinen Algorythmus nachdenkt um Wein statt Wasser aus dem Stein zu quetschen. :-) > Einen externen Bus hat er wohl auch nicht, mit seinen max. 80 > Pins. > Dann doch lieber 'nen AVR oder besser einen R32C :-) Stimmt, mit 144Pins kann man auch schonmal 1Mbyte externes Ram anschliessen ohne weinen zu muessen weil kaum noch was uebrig bleibt. Man sollte seinen Controller lieber nach der Qualitaet der Enwicklungsumgebung aussuchen. Das scheint mir in der Praxis einen groesseren Einfluss zu haben als daruber nachzusinnen ob ein Prozessor nun ein Register mehr oder weniger hat. Olaf
@Иван S. (ivan) Nimm meine Meinung bitte nicht persönlich! >Irgendwie scheinen manche Leute auf Akkumulatoren allergisch, ich kann >mir jedoch nicht erklären warum. Für jeden ..urz muß man den Accu sichern; das nervt auf Dauer. Bei einer CPU mit vielen Registern lasse ich R0 unberührt und rechne mit z.B. R5 weiter, was ich dann als Indexregister zu R3 nehme, um auf ein Array zuzugreifen. Gut, bei C-Kompilaten muß man das nicht mehr beachten, da der Compiler das erledigt; effizient ist es aber nicht. Darum mag ich eine Accu-CPU nicht. >Reichen Dir die 6k SRAM nicht? Mal ja, mal nein; und wenn man mehr braucht, ist Sense! Selbst ein 8051 hat da bessere Karten, auch wenn er nicht so schnell sein mag. >Jeder wie er will. Ich werde mir den STM8 jedenfalls noch länger genauer >ansehen. Hast Du denn Anwendungen mit hohen Stückzahlen? Dann kann ich das verstehen. Andernfalls ist es nur Spielerei, was ja nicht schlimm ist. Aber dann spiele ich lieber mit Teilen, mit denen man mehr gewinnen kann :-)
Ich mag auch ST. Der kleinste STM32F100 beginnt bei Stückpreisen schon bei 0,85 EUR (Digikey). Erst wenns weniger kosten oder wenn weniger Stromverbrauch sein soll, ist für mich ein STM8 interessant.
ein 6502 oder 8051 ????? Das ist kein Vergleich !!!!. Der STM8 ist um grössenordnungen scheller (betr der Taktzahl UND betr der Frequenz)!! ----------------------------------------------------- Es interssiert auch nicht ob man das 'Register' nun Akku nennt oder R1. Und: weil vieles Rechnen (mit src = mem) mit nur 1 Takt möglich ist, sind oft weitere Reg überhaupt nicht nötig. und: der STM8 kann sogar MOV Mem,Mem machen!!! Es wird also in diesem Fall ein 'Register' nichtmal benötigt. ..und das mit nur einem Takt ! (Kann das der 8051 auch ?) --------- (und, ein AVR braucht ewig lange, um Bytes von Mem nach Reg (oder Reg nach Mem) zu transferieren, so das eine Akkumaschine oft schneller als RISC ist (erst recht dann wenn diese Akkumaschine vieles mit nur 1 Takt machen kann)) ----------------------------------------------------- Ein externen Bus ist für die Zielanwendungen der typ 8Biter meistens nicht vorgesehen, weil schlichtweg (meist) nicht benötigt, da das interne SRAM normal ausreichend ist (bzw der Controller schon so ausgewählt werden sollte, dass es ausreicht, und die Perif norm auch reicht. Und irgentwas kleines kann man auch so noch an die IOs 'dranschustern'. Wenn man eine Anwendung mit externem (leistungsfähigen) Bus vorsehen will, würde ich den STM8 definitiv nicht mehr nehmen. (aber auch kein AVR, weil auch zu langsam , (auch M16C rel langsam) ) ----------------------------------------------------- Natürlich kann der STM8 insgesamt gesehen nicht mit grossen 32Bitern mithalten , weil insges viel weniger Befehle usw. Aber der STM8 kostet evtl nur 1/10 (!!!) von dem was grosse kosten. Und für diesen Preis (evtl < 1eu) hat er eine sehr hohe Leistung. ...besser als andere (wie ich meine) Wenn aber nur mit 8 Bit gerechnet werden soll (ohne ext.Bus), ist der STM8 evtl schneller, als 'grosse' 32Biter, obwohl er nur 1/10 so viel kostet ! -------------------- und die Periferie ist auch sehr gut: bsp viel mehr Möglichkeiten bei den Ports (5Reg) als bei AVR (3Reg). , auch SPI bidir.D. möglich --------------------
(nachtrag) Und wo keine zig Register sind, müssen auch keine zig Register beim Context-Switch umgeladen werden, und somit sind beim Context-Switch auch keine zig Takte nötig. ...auch hier sind viele "grosse" langsamer. --------------------------------- Meiner Meinung nach hat AVR mit dem STM8 eine sehr grosse Konkurenz bekommen. AVR müsste nachlegen: u.a. mit schnelleren LD/ST's
Tropenhitze schrieb: > @Иван S. (ivan) > Nimm meine Meinung bitte nicht persönlich! Keineswegs, wiso sollte ich eingeschnappt sein? Immerhin geht es hier um so profane Dinge wie MCUs und Geschmäcker sind bekanntlicher Weise verschieden. > Für jeden ..urz muß man den Accu sichern; das nervt auf Dauer. Bei einer > CPU mit vielen Registern lasse ich R0 unberührt und rechne mit z.B. R5 Naja, da sehe ich nicht so den Flaschenhals. Den Akku auf den Stack oder sonstwohin ins RAM zu schieben dauert ja keine Ewigkeiten. Aber ich verstehe dein Argument. Andererseits mag es auch bei registerorientierten Maschinen vorkommen, daß die Register gesichert werden müssen. > weiter, was ich dann als Indexregister zu R3 nehme, um auf ein Array > zuzugreifen. Der STM8 hat zwei 16 Bit breite Indexregister, X und Y. Mir reicht das. > Gut, bei C-Kompilaten muß man das nicht mehr beachten, da der Compiler > das erledigt; effizient ist es aber nicht. Ich möchte Assembler verwenden, das macht die Sache bestimmt effizienter ;-) > Darum mag ich eine Accu-CPU nicht. Das sei Dir ja auch unbenommen. Ich mag sie eben. >>Reichen Dir die 6k SRAM nicht? > > Mal ja, mal nein; und wenn man mehr braucht, ist Sense! Selbst ein 8051 > hat da bessere Karten, auch wenn er nicht so schnell sein mag. Ich hab' mal eben bei SiLabs, Atmel, Analog, TI und NXP die entsprechenden parametrischen Suchen bemüht, was ich gefunden habe hat mich ernüchtert: NXP: größter 80C51er hat 8k RAM, dafür nur 64k Flash. TI: "Up to 32 kB Flash, up to 1.2 kB RAM" sagt wohl alles, dafür angebich einen 24-Bit-ADC. Analog: Maximal 62k Flash, 2304 Bytes SRAM. Preis: 5 Dollar/Stk. bei Abnahme von Tausend. Atmel: Genau 1 Typ mit 8k RAM und 128k Flash, hat aber weder ADC noch I2C. Ein weiterer Typ mit 4k RAM und 64k Flash. SiLabs: Vier Typen mit 8k RAM und 128k Flash. Zugegeben: externes Speicherinterface vorhanden. So viele Vorteile für den 8051er sehe ich da nicht, vielleicht habe ich aber auch nur bei den falschen Herstellern gesucht. So schlecht sind die 6k des STM8 also gar nicht. Und ich würde fast wetten darauf, daß ST noch größere Derivate rausbringt, 256k Flash sind dort ja schon im Gespräch, vielleicht kommen als nächstes ja dann 8 oder 10k SRAM. Ich kann mir mittelfristig einen STM8 mit 16k RAM und 512k Flash durchaus vorstellen, auch wenn mir nicht eingehen mag, wozu man bei einem 8-Bitter so viel RAM braucht. Wer Megabytes an RAM und Hektarbytes an Flash braucht, ist möglicher Weise bei den 8-Bittern einfach nicht richtig, IMO. >>Jeder wie er will. Ich werde mir den STM8 jedenfalls noch länger genauer >>ansehen. > > Hast Du denn Anwendungen mit hohen Stückzahlen? Dann kann ich das > verstehen. Andernfalls ist es nur Spielerei, was ja nicht schlimm ist. Ich habe keine hohen Stückzahlen, das ist nur mein Hobby, Spielerei. > Aber dann spiele ich lieber mit Teilen, mit denen man mehr gewinnen kann > :-) Naja, womit kann man denn Deiner Meinung nach mehr "gewinnen"? Übrigens muß es ja meiner Meinung nach nicht immer nur um's Gewinnen gehen. Hobby soll in erster Linie Spaß machen. Lieber Gruß, Iwan
Hi >Atmel: Genau 1 Typ mit 8k RAM und 128k Flash, hat aber weder ADC noch >I2C. Ein weiterer Typ mit 4k RAM und 64k Flash. Zumindest bei Atmel hast du dich vertan: ATmega640/1280/1281/2560/2561 AT90USB1286/1287 Alle mit 8k Ram,I2C, und ADC. So jetzt streitet weiter. MfG Spess
spess53 schrieb: > Zumindest bei Atmel hast du dich vertan: > > ATmega640/1280/1281/2560/2561 > AT90USB1286/1287 > Alle mit 8k Ram,I2C, und ADC. Wenn ich das recht sehe, sind das AVRs. Es ging aber um 8051er. > So jetzt streitet weiter. Ich sehe keinen Streit, nur eine ausgesprochen sachliche Diskussion. > MfG Spess Gruß, Iwan
> Aber der STM8 kostet evtl nur 1/10 (!!!) von dem was grosse kosten.
(STM32 Cortex M3)
Wie, gibt es etwa den STM8 ab 0,085 EUR / Stück?
Иван S. schrieb:
> Es ging aber um 8051er.
Dann gugg mal bei ST selber: uPSD32XX
--Zu Preis-vergleich-- Ein ST32.. kostet min. noch 2,5..3x mehr (bsp EBV) als ein STM8, (und M32C..CPUs kosten ca 6..9eu), somit liegen die 32Biter in einer ganz anderen Preisregion und sind somit nicht vergleichbar
Relegionskriege liegen ja seit je her im Trend, nicht nur zu Ostern . . . ;-) Amen!
Das Hauptproblem von Иван S. ist doch, daß er die Firma Atmel nicht mag (warum auch immer). Deshalb muß er eben notgedrungen den STM8 nehmen. Alle anderen müssen deswegen nicht umlernen. Sie können weiterhin den AVR und das bequeme AVRStudio mit dem C-Compiler WINAVR nehmen. Und werden weiterhin hier und bei AVRfreaks viel Support bei ihren Fragen finden. Peter
MCUA schrieb: > ein 6502 oder 8051 ????? Das ist kein Vergleich !!!!. > Der STM8 ist um grössenordnungen scheller (betr der Taktzahl UND betr > der Frequenz)!! Gegenüber einem modernen 8051? Eher nicht, die SiLabs-Teile laufen schon lange mit bis zu 100 MHz und führen die meisten Befehle in einem/zwei Taktzyklus aus (keine 12 und 24-Zyklen wie bei den ersten 8051ern). Einziger Vorteil des STM8 sind die besseren Addressierungsarten. In wie weit die Compiler diese auch ausnutzen ist dann ein anderes Problem. > ----------------------------------------------------- > Es interssiert auch nicht ob man das 'Register' nun Akku nennt oder R1. > Und: weil vieles Rechnen (mit src = mem) mit nur 1 Takt möglich ist, > sind oft weitere Reg überhaupt nicht nötig. > und: der STM8 kann sogar MOV Mem,Mem machen!!! Es wird also in diesem > Fall ein 'Register' nichtmal benötigt. ..und das mit nur einem Takt ! > (Kann das der 8051 auch ?) Nur im iram. > --------- > (und, ein AVR braucht ewig lange, um Bytes von Mem nach Reg (oder Reg > nach Mem) zu transferieren, so das eine Akkumaschine oft schneller als > RISC ist (erst recht dann wenn diese Akkumaschine vieles mit nur 1 Takt > machen kann)) Bei "komplexeren" Berechnungen ist eine Akkumaschine nie schneller als ein RISC, da bei der Akkumaschine viel zu viele unnötige Load/Stores gemacht werden müssen bis das Ergebnis vorliegt. Der Unterschied zw. STM8 und 8051 dürfte dabei gegen Null gehen (abgesehen vom langsameren Takt des STM8), da der STM8 zwar bessere Addressierungsarten hat, aber keine zusätzlichen Register (R0-R7) wie der 8051 hat. "Vernünftige" 8-Bitter gibt's nur von Xemics (jetzt Semtech, die anscheinend auch kein Interesse haben, den Controller bekannter zu machen, obwohl schon gut 10 Jahre auf dem Markt) vier Datenregister, vier 16-Bit Indexregister, drei Operanden-Befehle und einen Akku der für Zwischenergebnisse benutzt werden kann, dazu mul und bedingte moves http://xemics.com/docs/xe8000/coolrisc816_databook.pdf > ----------------------------------------------------- > Natürlich kann der STM8 insgesamt gesehen nicht mit grossen 32Bitern > mithalten , weil insges viel weniger Befehle usw. Der STM8 kennt 96 Befehle... > Aber der STM8 kostet > evtl nur 1/10 (!!!) von dem was grosse kosten. Und für diesen Preis > (evtl < 1eu) hat er eine sehr hohe Leistung. ...besser als andere (wie > ich meine) 1/10 funktioniert nicht, wenn man gleiche Flash/SRAM-Größen ansetzt (die den meisten Platz beanspruchen). Gate-Count 8051 vs Cortex-M0 im besten Fall 1:2, gegenüber dem M3 1:3 - 1:6. Angaben ARM bzw. Mentor und evatronix.
Иван S. schrieb: > Mir persönlich gefallen > Akkumulator-Architekturen jedenfalls recht gut. Ob das Register jetzt A > heisst oder R0 ist doch eigentlich egal. Irgendwie scheinen manche Leute > auf Akkumulatoren allergisch, ich kann mir jedoch nicht erklären warum. Ich mir schon. Beispielsweise haben optimierende Compiler dazu eine deutlich andere Ansicht und diesbezüglich bin ich etwas vorbelastet. GCC/PCC für Akku-Architektur sind grosser Mist. Auch in Assembler sind Datentypen >Akkubreite ausgesprochen umständlich zu handhaben, es findet sehr viel eigentlich redundantes Hin- und Hergeschubse statt. > Jeder wie er will. Ich werde mir den STM8 jedenfalls noch länger genauer > ansehen. Schaun wir mal. Ist nicht deine erste Liebe, wenn ich mich recht erinnere. ;-)
ST schrieb: > Иван S. schrieb: >> Es ging aber um 8051er. > Dann gugg mal bei ST selber: uPSD32XX Nicht schlecht, bis zu 32k RAM und 288k Flash! Komisch, daß die uPSDs alle mit Status "Not reconmended for new designs" gelistet sind. Schade, immerhin wäre das der "Killer" unter den 8051ern. MCUA schrieb: > Wenn aber nur mit 8 Bit gerechnet werden soll (ohne ext.Bus), ist der > STM8 evtl schneller, als 'grosse' 32Biter, obwohl er nur 1/10 so viel > kostet ! Markus Müller schrieb: > Wie, gibt es etwa den STM8 ab 0,085 EUR / Stück? Weder gibt es einen STM8 um 9 cent, noch einen Cortex-M3 um 85 Eurocent. Der billigste bei DigiKey lagernde STM32, der STM32F101 kostet 4,79 Euro, hat 4k RAM und bescheidene 16k Flash. Leider hat DigiKey keinen STM8 mit 4k RAM lagernd, der STM8S207 hat nur 2k RAM, dafür 128k Flash und kostet 3,28 Euro. Einen STM8 mit 4k gibt's zum Beispiel bei Farnell, der STM8F202 mit 4k RAM und 64k Flash kostet dort einzeln 3,45 Euro, im Zehner nur mehr 2,88 Euro (leider gibt es diese Staffelpreise bei DigiKey nicht). Der Cortex kostet also bei wesentlich weniger Flashspeicher das 1,7-fache als Einzelstück. Wobei man natuerlich beachten muß, daß 32-Bit-Code in der Regel größer ist, der 8-bitter also effizienter. Butter bei die Fische, ich habe bei ST selbst nochmal nachgesehen: STM32 Value Line: "Volume production will begin from March 2010, at prices from $0.85 for 16Kbyte devices [...] for quantities of 10,000 units." STM8: "March, 2009 [...] The price for the 32 Kbyte STM8S105 [...] is $0.89 for quantities of 10,000 units." Inzwischen dürfte der STM8F105 nochmals deutlich billiger sein, Preis-Leistungs-Sieger ist meiner Meinung nach der STM8. Von Sparsamkeit in Sachen elektrischer Energie will ich erst gar nicht anfangen, da zieht der Cortex klar den kürzeren. Arc Net schrieb: > Bei "komplexeren" Berechnungen ist eine Akkumaschine nie schneller als > ein RISC, da bei der Akkumaschine viel zu viele unnötige Load/Stores > gemacht werden müssen bis das Ergebnis vorliegt. Ein RISC kann aber in den seltensten Fällen dividieren. Der STM8 macht eine 16Bit durch 16Bit-Division in maximal 17 Maschinenzyklen. Und der OpCode dazu ist nur 1 Byte lang. Ein Laden Register/Speicher oder umgekehrt dauert nur einen Maschinenzyklus. Ein RISC kann das auch nicht schneller. Klar, der RISC hat generell mehr Register. Aber was nutzt das schon, wenn er sich bei zum Beispiel R5 durch R17 zutodedividiert? Er kann deswegen auch nichts nebenbei machen, die restlichen 15 Register gammeln vor sich hin und halten ihre Daten. Selbst wenn der RISC unwahrscheinlicher Weise also sagen wir "DIV R5,R17" ausführen kann, wird es nicht schneller sein als auf dem CISC. Und was das Laden und Speichern betrifft: Das musst Du doch beim RISC auch, irgendwie müssen doch die Werte vom Speicher in die Register und umgekehrt. Klar, du hast mehr Register, aber ich sehe den Akku da nicht wirklich als Flaschenhals. A. K. schrieb: >> Jeder wie er will. Ich werde mir den STM8 jedenfalls noch länger genauer >> ansehen. > > Schaun wir mal. Ist nicht deine erste Liebe, wenn ich mich recht > erinnere. ;-) Da hast DU allerdings recht. Bei den Toshibas hat es damals nicht geklappt, da die Doku unvollständig war und die eZ8 hatten teilweise Bugs und sind mir gestorben wie die Fliegen. Hoffentlich habe ich jetzt die "Liebe für's Leben" gefunden. Gruß an alle, Iwan
8051 ist in der Tat eine >>olle Camelle<<, mit der ich nichts (mehr) zu tun haben will (dad ding kann auch nicht adressieren !), die Firmen, die 51er Cores machen, können nichts anderes als das alte Zeug weiter zu betreiben, bzw trauen sich nicht was neues zu entwickeln. Eine 51er Architektur kann weder mit typ RISC noch mit CISC mithalten. (schon alleine wegen den 'gigantischen' Adressierungsarten) ---------------------------------------------- Arc Net schrieb: > Bei "komplexeren" Berechnungen ist eine Akkumaschine nie schneller als > ein RISC, da bei der Akkumaschine viel zu viele unnötige Load/Stores > gemacht werden müssen bis das Ergebnis vorliegt. Mit einem AVR kann man fast gar nicht so "komplex" rechnen, als das die Taktzyklen für LD/ST nicht ins Gewicht fallen. Im Gegenteil: schon wenige Werte aus Mem genommen benötigen etliche Taktcyklen (ca 3..4 Takte je Wert.) Bei STM8 sind oft dazu nichtmal ein Takt nötig, da der bei Math-Bef (1Takt) schon selbst die Werte aus dem mem nimmt. Wenn man also viele Werte aus Mem nehmen muss, die in die Berech einfliessen, kann man einfach den Math-Bef nehmen, OHNE irgent einen zus Takt für LD/ST. So ist eine Akkumsch (hier STM8), besonders wenn sie die Berechn mit mem mit nur 1 Takt ausführen kann, oft mehrfach schneller als der AVR. Bspweise 100Werte verrechnet und aus Mem genommen sind 100Takte f befehl und evtl 3..4 Bef zum rückschreiben. Also 100+4=104 Takte. Beim AVR müsste man nicht nur 100x den Math-Bef ausführen (100 Takte), sondern auch noch 100x den Wert (irgentie) ins Reg laden, also evtl plus 100 x (3..4 Takte) = 3..400 Takte, somit sinds dann beim AVR sage und schreibe ges. 4..500 Takte. !!! In diesem Fall ist die Akku-masch. deutlich schneller. Und meistens hat man rel. viele Werte aus Mem, die verrechnet werden sollen und rel. wenige Werte, die zurück geschrieben werden. Es müssen also viel öfter Werte aus Mem gelesen werden als in Mem geschrieben werden, und genau da braucht eine CISC-Akkumsch viel weniger Takte ! Und bei AVR muss für jeden Kikifaks zig Takte geopfert werden, nur um den Wert erstmal in Reg zu laden. Das Reg-File ist auch bei weitem zu klein, als dass die relevanten Werte alle reinpassen würden. (schliesslich ist das RAM ja nicht umsonst 1k oder mehr gross), es muss also bei RISC ständig hin und hergeschoben werden!!!!! Bei Akku-masch entfällt das bei vielen Befehlen. (Die alten Akku-masch HC8,11,12, ST6,7) waren dies. bez. aber schlechter, weil die etliche Takte für fast jeden Befehl benötigt haben, da war der AVR evtl etwas schneller. Aber mit STM8-fast-alles-in-1-Takt- wird der Spiess umgedreht)
@Иван S. Bevor Du Dich voll und ganz dem STM8 hinwirfst, empfehle ich dennoch einmal ein paar Datenblätter des STM32F10x an zu schauen. Natürlich hat der ein paar Bits mehr (24), aber ich denke die eingebaute Pheriperie und die vielen Derivate und die Verfügbarkeit machen gerade den STM32 für den Hobby-Bereich sehr interessant. Zumal da auch GCC geht (auch der Assembler :) ) und man somit eine kostenlose Software für Win / Linux im Internet hat. PS: Interrupt benötigt für den Einsprung nur 12 Clocks und für das verlassen ebenfalls nur 12. Dabei werden automatisch die Register gesichert. Es lohnt sich wirklich! Einfach mal reinschnuppern, davon geht die Welt nicht unter. (Ja ich Weiß, jemand der an Gott glaubt kann man schlecht für den Teufel überzeugen...)
Da ich jung und für alles Neue total aufgeschlossen bin, helft mir doch einmal mit den Ausführungszeiten auf die Sprünge. int16 Divisionen brauch ich eher selten, aber sehr oft brauche ich die Division 1.234567/9.876543, wobei der Divisor sich immer leicht ändert und daher keine Konstante verwendet werden kann. Wie lange dauert die float32-Divison auf einem STM8? Bitte konkrete Angaben in µs!
>Solche Zahlen werden doch so gerechnet:
Heute ist nicht der 1. April sondern der 5. April. Und der 5. April ist
nicht 5 x der 1. April. Und darum brauche ich konkrete Zahlen.
Tropenhitze schrieb: > sehr oft brauche ich die Division 1.234567/9.876543, wobei der Divisor > sich immer leicht ändert Aha, daher weht der Wind... Tropenhitze schrieb: > Und darum brauche ich konkrete Zahlen. Schau' mal in die Doku zu Deiner Fließkommazahlenbibliothek. Wie oft ändert sich denn der Divisor? Iwan
Иван S. schrieb: > Zehner nur mehr 2,88 Euro (leider gibt es diese Staffelpreise bei > DigiKey nicht). Der Cortex kostet also bei wesentlich weniger > Flashspeicher das 1,7-fache als Einzelstück. Wobei man natuerlich > beachten muß, daß 32-Bit-Code in der Regel größer ist, der 8-bitter also > effizienter. Hätte man bei gewöhnlichen RISCs unterschreiben können, beim Thumb-2-Befehlssatz sieht das deutlich anders aus. > > Butter bei die Fische, ich habe bei ST selbst nochmal nachgesehen: > STM32 Value Line: "Volume production will begin from March 2010, at > prices from $0.85 for 16Kbyte devices [...] for quantities of 10,000 > units." > STM8: "March, 2009 [...] The price for the 32 Kbyte STM8S105 [...] is > $0.89 for quantities of 10,000 units." Die Cortex-M0 LPC1100 werden das wohl unterbieten... > in Sachen elektrischer Energie will ich erst gar nicht anfangen, da > zieht der Cortex klar den kürzeren. Eher nicht, LPC13xx etwa 4mA @ 12 MHz typ. , stm8s105xx 7 mA @ 16 MHz typ., die Cortex-M3 von EnergyMicro liegen nochmals darunter, ebenso kommende Cortex-M0 (LPC11xx 9 mA @ 50 MHz)... > > Arc Net schrieb: >> Bei "komplexeren" Berechnungen ist eine Akkumaschine nie schneller als >> ein RISC, da bei der Akkumaschine viel zu viele unnötige Load/Stores >> gemacht werden müssen bis das Ergebnis vorliegt. > > Ein RISC kann aber in den seltensten Fällen dividieren. Cortex-M3 sdiv, udiv... > Der STM8 macht > eine 16Bit durch 16Bit-Division in maximal 17 Maschinenzyklen. Und der > OpCode dazu ist nur 1 Byte lang. Ein Laden Register/Speicher oder > umgekehrt dauert nur einen Maschinenzyklus. Ein RISC kann das auch nicht > schneller. Klar, der RISC hat generell mehr Register. Aber was nutzt das > schon, wenn er sich bei zum Beispiel R5 durch R17 zutodedividiert? Er > kann deswegen auch nichts nebenbei machen, die restlichen 15 Register > gammeln vor sich hin und halten ihre Daten. Selbst wenn der RISC > unwahrscheinlicher Weise also sagen wir "DIV R5,R17" ausführen kann, Das ist normal, weil die klassischen RISCs alle 3-Operanden-Befehle kennen also op dest, src1, src2 wie der genannte sdiv beim Cortex-M3. > wird es nicht schneller sein als auf dem CISC. Und was das Laden und > Speichern betrifft: Das musst Du doch beim RISC auch, irgendwie müssen > doch die Werte vom Speicher in die Register und umgekehrt. Klar, du hast > mehr Register, aber ich sehe den Akku da nicht wirklich als > Flaschenhals. Dann sieh dir mal den Code, den gängige Compiler produzieren, oder schreibe mal die SHTxx Feuchteberechnung RHL = c1 + c2 * sorh + c3 * sorh^2 T = d1 + d2 * sot RHT = (T - 25) * (t1 - t2 * sorh) + RHL einmal für den Cortex-M3 mit ldm, mla, mul etc. und dann einmal das ganze für den STM8 (der nur 8-Bit-Multiplikationen durchführt) MCUA schrieb: > Bei STM8 sind oft dazu nichtmal ein Takt nötig, da > der bei Math-Bef (1Takt) schon selbst die Werte aus dem mem nimmt. Gerade da nicht: MUL braucht die Werte im Akku und in einem Index-Register, bei ADD ist das Ziel auch immer der Akku. Macht das Beispiel von oben für den STM8 zwar etwas einfacher, aber trotzdem weit aufwendiger. > Bspweise 100Werte verrechnet und aus Mem genommen sind 100Takte f > befehl und evtl 3..4 Bef zum rückschreiben. Z.B. sowas
1 | uint8_t array[100]; |
2 | uint16_t res = 0; |
3 | for (int i = 0; i < 100; i++) res += array[i]; |
Nur kennt der STM8 kein Postinkrement, braucht somit ein zusätzliches INCW, das auch noch zwei Taktzyklen dauert...
Иван S. schrieb: > Wobei man natuerlich > beachten muß, daß 32-Bit-Code in der Regel größer ist, der 8-bitter also > effizienter. Wissen oder Vermutung? Das hängt stark vom Programm ab. Bei kleinen stark I/O-orientierten Programmen trifft das schon der Adressbreite wegen zu. Bei grösseren Programmen (z.B. in der Kategorie von Devices mit 64-128K Flash) kann es ebensogut andersrum aussehen. Für die Daten trifft das freilich meistens schon zu, weshalb ARM-Controller bei gleicher Flash-Grösse üblicherweise mehr RAM besitzen. > Klar, der RISC hat generell mehr Register. Aber was nutzt das > schon, wenn er sich bei zum Beispiel R5 durch R17 zutodedividiert? Der Division wird im Kontext von Controllern erst die heutige Bedeutung geschenkt, seit die Konkurrenz sich dadurch von den ARM7 absetzen wollte und ARM wiederum Argumente brauchte, um den Bestandskunden den neuen Cortex-M3 Core verkaufen zu können. Davor war man sich einigermassen einig, dass Multiplikation weit wichtiger ist als Division.
@ MCUA (Gast) Passend zu Ostern, ein neuer Kreuzzug. STM8 gegen den Rest der Welt. Süß ;-) >Im Gegenteil: >schon wenige Werte aus Mem genommen benötigen etliche Taktcyklen (ca >3..4 Takte je Wert.) Bei STM8 sind oft dazu nichtmal ein Takt nötig, Nicht mal einen Takt, soso. Für alle Interessierten, das Instruction Manual. http://www.st.com/stonline/products/literature/pm/13590.pdf Man sollte mal genau lesen, und nicht nur die Marketingübersicht. Und was sieht man da? >kann man einfach den Math-Bef nehmen, OHNE irgent einen zus Takt für >LD/ST. So ist eine Akkumsch (hier STM8), besonders wenn sie die Berechn >mit mem mit nur 1 Takt ausführen kann, oft mehrfach schneller als der >AVR. ;-) Eiferer sind bisweilen etwas einseitig in ihrer Wahrnehmung. > Bspweise 100Werte verrechnet und aus Mem genommen sind 100Takte f > befehl und evtl 3..4 Bef zum rückschreiben. Also 100+4=104 Takte. Kaum. Denn auch dein Index muss erhöht werden, was mal mindest einen Takt dauert. Und bei jedem Schleifendurchlauf muss auf das Ende geprüft werden. >Beim AVR müsste man nicht nur 100x den Math-Bef ausführen (100 Takte), >sondern auch noch 100x den Wert (irgentie) ins Reg laden, also evtl plus >100 x (3..4 Takte) = 3..400 Takte, somit sinds dann beim AVR sage und >schreibe ges. 4..500 Takte. !!! Dein Heilland, ähhhh, STM8 braucht mindestens genauso viel. Und was passiert, wenn man 100 Bytes summiert sollte den Meisten klar sein. Es kommt was mit 16 Bit raus. Und da sieht dein STM8 ziemlich mau aus. Denn dort muss die 16 Bit Akkumulation ziemlich nervig zusammengestückelt werden. Soviel zum Thema ;-) >In diesem Fall ist die Akku-masch. deutlich schneller. Dream on. Ist dir nicht schon mal die Frage in den Sinn gekommen, warum so ziemlich ALLE aktuellen Prozessoren, egal ob kleiner uC oder großer QuadCore Pentium, eher Registermschinen sind? >Und meistens hat man rel. viele Werte aus Mem, die verrechnet werden >sollen und rel. wenige Werte, die zurück geschrieben werden. Es müssen >also viel öfter Werte aus Mem gelesen werden als in Mem geschrieben >werden, und genau da braucht eine CISC-Akkumsch viel weniger Takte ! Nö. Zaubern kann die auch nicht. >Und bei AVR muss für jeden Kikifaks zig Takte geopfert werden, nur um >den Wert erstmal in Reg zu laden. Dann steht er aber dort und kann beliebig verarbeitet werden. > Das Reg-File ist auch bei weitem zu >klein, als dass die relevanten Werte alle reinpassen würden. ;-) Der große Weise spricht. Sind ja nur 32 Register, da kann man ja nicht mal ne LED blinken lassen. >(schliesslich ist das RAM ja nicht umsonst 1k oder mehr gross), ??? Es gibt AVRs ohne RAM, nur mit 32 Registern. Und mit denn kann man sogar was anfgangen. > es muss >also bei RISC ständig hin und hergeschoben werden!!!!! Bei Akku-masch >entfällt das bei vielen Befehlen. Stimmt, die rechnen nur im Akku oder RAM. >(Die alten Akku-masch HC8,11,12, ST6,7) waren dies. bez. aber >schlechter, weil die etliche Takte für fast jeden Befehl benötigt haben, >da war der AVR evtl etwas schneller. Aber mit STM8-fast-alles-in-1-Takt- >wird der Spiess umgedreht) Knieet nieder, der Heilland kommt. MFG Falk
Arc Net schrieb: > Иван S. schrieb: >> Zehner nur mehr 2,88 Euro (leider gibt es diese Staffelpreise bei >> DigiKey nicht). Der Cortex kostet also bei wesentlich weniger >> Flashspeicher das 1,7-fache als Einzelstück. Wobei man natuerlich >> beachten muß, daß 32-Bit-Code in der Regel größer ist, der 8-bitter also >> effizienter. > > Hätte man bei gewöhnlichen RISCs unterschreiben können, beim > Thumb-2-Befehlssatz sieht das deutlich anders aus. Kennt Thumb überhaupt 1-Byte-Befehle? >> Butter bei die Fische, ich habe bei ST selbst nochmal nachgesehen: >> STM32 Value Line: $0.85 for 16Kbyte devices [...] 10.000 >> STM8: 32 Kbyte STM8S105 [...] is $0.89 [...] 10,000 units. > > Die Cortex-M0 LPC1100 werden das wohl unterbieten... Möglich, nur wie lange? Ich kann mir STM8-ICs vorstellen mit 16 MBit Flash. 8 Bit bleibt weiterhin konkurrenzfähig, das will ich damit sagen. Klar, die Cortexen haben RAMs in der Grössenordnung einiger zig MByte. Auch das könnte man beim STM8, dank Verwendung der 130nm-Technologie, auf sagen wir, 512kByte aufblasen, immerhin kann man 16 MByte linear addressieren. Die Flexibilität in der Technologie ist der Kernpunkt meiner Aussagen, welche vorallem meinem Motto geschzuldet ist: "8-bittige Controller werden immer konkurrenzfähig bleiben!" >> in Sachen elektrischer Energie will ich erst gar nicht anfangen, da >> zieht der Cortex klar den kürzeren. > > Eher nicht, LPC13xx etwa 4mA @ 12 MHz typ. , stm8s105xx 7 mA @ 16 MHz > typ., die Cortex-M3 von EnergyMicro liegen nochmals darunter, ebenso > kommende Cortex-M0 (LPC11xx 9 mA @ 50 MHz)... Ich spreche von der Liga 150nA. Dort liegt die Zukunft! >> Arc Net schrieb: >>> Bei "komplexeren" Berechnungen ist eine Akkumaschine nie schneller als >>> ein RISC, da bei der Akkumaschine viel zu viele unnötige Load/Stores >>> gemacht werden müssen bis das Ergebnis vorliegt. >> >> Ein RISC kann aber in den seltensten Fällen dividieren. > > Cortex-M3 sdiv, udiv... > >> Der STM8 macht >> eine 16Bit durch 16Bit-Division in maximal 17 Maschinenzyklen. Und der >> OpCode dazu ist nur 1 Byte lang. Ein Laden Register/Speicher oder >> umgekehrt dauert nur einen Maschinenzyklus. Ein RISC kann das auch nicht >> schneller. Klar, der RISC hat generell mehr Register. Aber was nutzt das >> schon, wenn er sich bei zum Beispiel R5 durch R17 zutodedividiert? Er >> kann deswegen auch nichts nebenbei machen, die restlichen 15 Register >> gammeln vor sich hin und halten ihre Daten. Selbst wenn der RISC >> unwahrscheinlicher Weise also sagen wir "DIV R5,R17" ausführen kann, > > Das ist normal, weil die klassischen RISCs alle 3-Operanden-Befehle > kennen also op dest, src1, src2 wie der genannte sdiv beim Cortex-M3. >> wird es nicht schneller sein als auf dem CISC. Und was das Laden und >> Speichern betrifft: Das musst Du doch beim RISC auch, irgendwie müssen >> doch die Werte vom Speicher in die Register und umgekehrt. Klar, du hast >> mehr Register, aber ich sehe den Akku da nicht wirklich als >> Flaschenhals. > > Dann sieh dir mal den Code, den gängige Compiler produzieren, oder > schreibe mal die SHTxx Feuchteberechnung > RHL = c1 + c2 * sorh + c3 * sorh^2 > T = d1 + d2 * sot > RHT = (T - 25) * (t1 - t2 * sorh) + RHL > einmal für den Cortex-M3 mit ldm, mla, mul etc. und dann einmal das > ganze für den STM8 (der nur 8-Bit-Multiplikationen durchführt) Es wäre zwar trivial, aber bei gleicher Taktung wären beide gleich schnell. -+ > MCUA schrieb: >> Bei STM8 sind oft dazu nichtmal ein Takt nötig, da >> der bei Math-Bef (1Takt) schon selbst die Werte aus dem mem nimmt. > > Gerade da nicht: MUL braucht die Werte im Akku und in einem > Index-Register, bei ADD ist das Ziel auch immer der Akku. Macht das > Beispiel von oben für den STM8 zwar etwas einfacher, aber trotzdem weit > aufwendiger. Sorry, ich bin dann bei Sachen wie "1.234567/9.876543 ganz genau oder auch nicht" ausgestiegen, 98/12 ist jedenfalls ungefähr 8. Klar, wenn alle Stellen signifikant sind wird der 8-bitter derzeit verlieren, aber die Zeiten ändern sich, das steht fest! >> Bspweise 100Werte verrechnet und aus Mem genommen sind 100Takte f >> befehl und evtl 3..4 Bef zum rückschreiben. > > Z.B. sowas >
1 | > uint8_t array[100]; |
2 | > uint16_t res = 0; |
3 | > for (int i = 0; i < 100; i++) res += array[i]; |
4 | >
|
> Nur kennt der STM8 kein Postinkrement, braucht somit ein zusätzliches > INCW, das auch noch zwei Taktzyklen dauert... Kann man auf dem Achtbitter genauso schnell implementieren wie auf dem 16bitter. 8 bit ist die Zukunft! Iwan
> Es gibt AVRs ohne RAM, nur mit 32 Registern. Und mit denn kann man sogar > was anfgangen. Ja sicher, es haben sich auch schon Leute mit einer Peitsche selber geschlagen und sich dabei gut gefuehlt. :-D Olaf
@ Иван S. (ivan) >Auch das könnte man beim STM8, dank Verwendung der 130nm-Technologie, >auf sagen wir, 512kByte aufblasen, immerhin kann man 16 MByte linear >addressieren. Sehr sinnvoll für einen 8 Bitter, bei den Preisen heutiger 32 Bitter. . . >"8-bittige Controller werden immer konkurrenzfähig bleiben!" 640 kB sind für immer ausreichend. ;-) Alles relativ. >Ich spreche von der Liga 150nA. Dort liegt die Zukunft! Aha, dein STM8 ist also am besten, wenn er ausgeschaltet ist. Wundert mich nicht ;-) >> Nur kennt der STM8 kein Postinkrement, braucht somit ein zusätzliches >> INCW, das auch noch zwei Taktzyklen dauert... >Kann man auf dem Achtbitter genauso schnell implementieren wie auf dem >16bitter. 8 bit ist die Zukunft! Du musst es wissen, du bist der CPU-Papst! MFG Falk, leider ohne PopCorn
Mein STM32 hat ein RTC Counter (32 Bit). Damit rechne ich die Zeit in D/M/Y H:M:S um. Wenn Du das in Assembler und 8Bit machen müsstest, dann würdest Du zum Elch werden. Hier der Code: Beitrag "Re: STM32 Uhrzeit des RTC Umrechnen"
Иван S. schrieb: > Kennt Thumb überhaupt 1-Byte-Befehle? Nein, aber kürzere Befehle sind nicht gleichbedeutend mit kürzeren Programmen- > Möglich, nur wie lange? Ich kann mir STM8-ICs vorstellen mit 16 MBit > Flash. Sowas programmiert auch der beste Иван nicht mehr in Assembler, sondern wahrscheinlich in C, möglicherweise auch in C++. Und wie sowas dann auf Maschinenebene aussieht, davon habe ich eine ungefähre Vorstellung. Es gibt wohl 8051-Versionen mit 1MB Flash. Aber nicht, weil sich damit besser programmiert als mit 1MB ARMs, sondern weil man die jenen Leuten verkaufen kann, die seit zig Jahren 8051er programmieren und sich nicht gern umstellen wollen, bloss weil das bestehende und immer weiter geflickte Programm mit der Zeit wächst und wächst. > 8 Bit bleibt weiterhin konkurrenzfähig, das will ich damit sagen. Sicher. Aber nicht weil die Programmierung darauf bei grossen Programmkapazitäten effizienter ist - das ist sie nicht - sondern weil sie bei kleinen Programmen umgänglicher sind und weil sie in 100000er Stückzahlen etwas billiger herzustellen sind. > Klar, die Cortexen haben RAMs in der Grössenordnung einiger zig MByte. > Auch das könnte man beim STM8, dank Verwendung der 130nm-Technologie, > auf sagen wir, 512kByte aufblasen, immerhin kann man 16 MByte linear > addressieren. Viel Vergnügen dabei. Mit 16-Bit Zeigern mehr als 64KB zu adressieren ist was für die ganz harten Jungs. Geht schon, aber bei jedem Pointer entscheiden zu müssen, ob der in kleinen oder grossen Adressraum zeigen soll, oder in RAM vs ROM, das nervt. Nervt mich auch an den AVRs, ich mag keine Adressraumtrennung. Meine persönliche Definition der benötigten Bitbreite der Architektur ist daher, dass diese Bitbreite ausreichen sollte, um mindestens das RAM geschlossen ohne Tricks und Paging adressieren zu können, vorzugsweise aber den gesamten linear adressierten Speicher. Das gilt gleichermassen für Mikrocontroller wie für PC/Server-Prozessoren - bei jenen liegt nämlich der Vorzug von 64-Bit Architekturen eher in der Fähigkeit, viel Speicher schmerzfrei adressieren zu können, als in der Breite der Arithmetik selbst. > Es wäre zwar trivial, aber bei gleicher Taktung wären beide gleich > schnell. Dir ist schon klar, dass diese SHT11-Rechnung mindestens teilweise mit 32-Bit Arithmetik durchgeführt werden muss? Sowas ist nicht wirklich die Stärke von 8-Bittern im Allgemeinen und von Akku-Architekturen im Besonderen.
Falk Brunner schrieb: > @ Иван S. (ivan) > >>Auch das könnte man beim STM8, dank Verwendung der 130nm-Technologie, >>auf sagen wir, 512kByte aufblasen, immerhin kann man 16 MByte linear >>addressieren. > > Sehr sinnvoll für einen 8 Bitter, bei den Preisen heutiger 32 Bitter. Meiner Meinung nach schon. Der Trend geht eindeutig hin in Richtung billiges SRAM. >>"8-bittige Controller werden immer konkurrenzfähig bleiben!" > > 640 kB sind für immer ausreichend. ;-) 16 MByte sind es, für die üblichen Einsatzzwecke der Controller. Generell wird es immer einen Preisverfall bei Halbleitern geben >>Ich spreche von der Liga 150nA. Dort liegt die Zukunft! > > Aha, dein STM8 ist also am besten, wenn er ausgeschaltet ist. Wundert > mich nicht ;-) "Low Power" ist sicher eine der Zukunftstechnologien im Halbleitersegment. Aber ich weiss ja, daß Du weisst was gemeint war! >>> Nur kennt der STM8 kein Postinkrement, braucht somit ein zusätzliches >>> INCW, das auch noch zwei Taktzyklen dauert... > >>Kann man auf dem Achtbitter genauso schnell implementieren wie auf dem >>16bitter. 8 bit ist die Zukunft! > > Du musst es wissen, du bist der CPU-Papst! Das Originalbeispiel war:
1 | > uint8_t array[100]; |
2 | > uint16_t res = 0; |
3 | > for (int i = 0; i < 100; i++) res += array[i]; |
Hier ist in der Tat der 16-Bitter schneller, nach gängiger Definition von "uint16_t res". Mit "uint8_t res" sähe es vermutlich besser aus ;-) > MFG > Falk, leider ohne PopCorn Ich hol' mir noch ein Bierchen. Ich hoffe dennoch, daß man Dir die 8-Bitter und die Akkumulatorarchitektur generell nicht madig gemacht hat. Würd' mich freuen, Iwan
Иван S. schrieb: > Meiner Meinung nach schon. Der Trend geht eindeutig hin in Richtung > billiges SRAM. Interessant. Lustigerweise sparen die Hersteller von kleineren Controllern nicht so sehr am hoch dichten Flash-ROM, sondern vorzugsweise am ausgesprochen platzraubenden SRAM und optimieren grössere Controller für externes DRAM statt externes SRAM.
@ Иван S. (ivan) >Ich hol' mir noch ein Bierchen. Ich hoffe dennoch, daß man Dir die >8-Bitter und die Akkumulatorarchitektur generell nicht madig gemacht >hat. Was will ich mit dem ollen Zeug? Ich hab (vor über 10 Jahren, ich werd alt) 8051 und 68HC11 programmiert, in ASM. Etwas später, gegen Ende des Studiums, hab ich den AVR kennengelernt. Seitdem hab ich keinerlei Bedürfnis, zu den ollen Akkumaschinen zurückzukehren, schon gar nicht in ASM. MfG Falk
A. K. schrieb: > Meine persönliche Definition der benötigten Bitbreite der Architektur > ist daher, dass diese Bitbreite ausreichen sollte, um mindestens das RAM > geschlossen ohne Tricks und Paging adressieren zu können, vorzugsweise > aber den gesamten linear adressierten Speicher. Klarstellung: Mir geht es hier um die Fähigkeit, mit 16/24/32-Bit breiten Adressen einigermassen effizient umgehen zu können. 8- und 16-Bit Typen können das oft bis 16 Bits also 64KB einigermassen ordentlich, es gibt aber Ausnahmen wie beispielsweise 6805 und PIC12-16.
A. K. schrieb: > Иван S. schrieb: > >> Meiner Meinung nach schon. Der Trend geht eindeutig hin in Richtung >> billiges SRAM. > > Interessant. Lustigerweise sparen die Hersteller von kleineren > Controllern nicht so sehr am hoch dichten Flash-ROM, sondern > vorzugsweise am ausgesprochen platzraubenden SRAM und optimieren > grössere Controller für externes DRAM statt externes SRAM. DRAM ist meiner Meinung nach der falsche Weg. Ich sehe die Zukunft eher in wesentlich schnellerem Flash, insbesondere beim Beschreiben. SRAM 64k, Flash deutlich über 64 MBit, was will man mehr? Nur meine subjektive Feiertagsmeinung, Iwan Ich erstelle wohl lieber einen Thread 8 Bit vs, >8 Bit. Im speziellen: "Akkumulator- vs. Registermaschine".
Иван S. schrieb: > DRAM ist meiner Meinung nach der falsche Weg. Ich sehe die Zukunft eher > in wesentlich schnellerem Flash, insbesondere beim Beschreiben. SRAM > 64k, Flash deutlich über 64 MBit, was will man mehr? Dein Wort in Gottes Ohr... Dummerweise wachsen und gedeihen die Waitstates bei Controllern mit (NOR-) Flash mit jedem MHz Taktfrequenz, egal ob in 130nm oder 90nm. Was tatsächlich im Durchsatz(!) besser wird ist das NAND-Flash der Sticks und SSDs, aber das ist eine völlig andere Baustelle, und führt bei grossen Controllern zu hochdichtem DRAM mit hohem Durchsatz(!) für direkt adressiertes Programm und Daten, und zu NAND-Flash als Disk-artige Programm/Datenquelle mit etwas NOR-Flash als Bootloader.
Иван S. schrieb: > Nur meine subjektive Feiertagsmeinung, > > Ich erstelle wohl lieber einen Thread 8 Bit vs, >8 Bit. Im speziellen: > "Akkumulator- vs. Registermaschine". Dürfen wir also morgen einen neuen Thread mit der gegenteiligen Wochentagsmeinung erwarten? ;-)
A. K. schrieb: > Иван S. schrieb: >> Ich erstelle wohl lieber einen Thread 8 Bit vs, >8 Bit. Im speziellen: >> "Akkumulator- vs. Registermaschine". > > Dürfen wir also morgen einen neuen Thread mit der gegenteiligen > Wochentagsmeinung erwarten? ;-) Nein, aber ich bin mit meinen 28 Lenzen wohl in der Erfinderzeit. Mich interessieren eben generelle Meinungen, ich selbst habe jedoch eine fixe. Ich beschäftige mich auch mit der Thematik "Freie Energie aus physikalischer Sicht", Metaphysik und Alchemie. Nicht alles ist Hokuspokus. Iwan
@Иван S. (ivan) >Nein, aber ich bin mit meinen 28 Lenzen wohl in der Erfinderzeit. Mich >interessieren eben generelle Meinungen, ich selbst habe jedoch eine >fixe. Aha, ein Forscher mit betoniertem Weltbild. Der Humbold würde im Grabe rotieren. >Ich beschäftige mich auch mit der Thematik "Freie Energie aus >physikalischer Sicht", Metaphysik und Alchemie. >Nicht alles ist Hokuspokus. *ROFL^3* Dein Talent als Komiker ist deutlich größer als deine E-Technik Fähigkeiten. Nix für ungut. MFG Falk
man braucht keinen Index, ADC Addition with Carry ADC (STM8) dst src ASM cy lgth Op-code(s) A #byte ADC A,#$55 1 2 A9 XX A shortmem ADC A,$10 1 2 B9 XX A longmem ADC A,$1000 1 3 C9 MS LS A (X) ADC A,(X) 1 1 F9 A (shortoff,X) ADC A,($10,X) 1 2 E9 XX A (longoff,X) ADC A,($1000,X) 1 3 D9 MS LS A (Y) ADC A,(Y) 1 2 90 F9 A (shortoff,Y) ADC A,($10,Y) 1 3 90 E9 XX A (longoff,Y) ADC A,($1000,Y) 1 4 90 D9 MS LS A (shortoff,SP) ADC A,($10,SP) 1 2 19 XX alle ob. Bef. gehen mit nur 1 Takt (das kommt nicht aus Prospekt) --------------------------------------------------- Ich vertrete nicht die Meinung, das der STM8 geg. den Rest der CPU-Welt antreten will, das wäre Quatsch. Aber für einen 8Biter ist der Baustein sehr schnell. Oft schneller als RISC, und allemal um einiges schneller als AVR (war selbst überrascht davon)
@ MCUA (Gast) >man braucht keinen Index, Für die Summation eines 100 Byte Arrays? soso. >antreten will, das wäre Quatsch. Aber für einen 8Biter ist der Baustein >sehr schnell. Oft schneller als RISC, und allemal um einiges schneller >als AVR ;-) Schreib mal ein funktionierendes Programm, das wenigstens im Simulator komplett läuft. Dann zähl mal die Takte. Dann reden wir weiter. MFG Falk
Falk Brunner schrieb: >>man braucht keinen Index, > Für die Summation eines 100 Byte Arrays? soso. Doch, da her er recht. Wenn's sein muss geht es auch ohne: add a,array+0 add a,array+1 add a,array+2 ... add a,array+99 und dabei ist der STM8 tatsächlich doppelt so schnell wie ein AVR (in Takten). Bei einer naheliegenderen 16-Bit Summe sähe es wohl wieder etwas anders aus.
Soviel zum Thema reale Anwendungsleistung . . . Der akademische Elfenbeinturm ist schon sehr kuschelig, schon klar.
Falk Brunner schrieb: > Soviel zum Thema reale Anwendungsleistung . . . Ganz so exotisch ist das nicht, wenn man es wirklich eilig hat. Nennt sich loop unrolling. Damit ist man ab 5fach unrolling bereits einen winzigen Hauch schneller als AVR. ;-) Eines muss man dem STM8 schon lassen: Es ist die m.W. erste Implementierung einer 68xx-ähnlichen Akku-Architektur, bei der die dafür typischen Load-Execute Befehle ohne zusätzliche Takte für Instruction Fetch und Adressrechnung auskommen. Dass man damit nur gewinnt, weil diese Prozessorklasse heute nicht (nur) durch den Core sondern massgeblich durch das Flash gebremst wird steht auf einem anderen Blatt. Wenn man die Cores von AVR und STM8 aus RAM ausgeführt mit maximal möglichem Takt fahren würde, dann würde der STM8 aufgrund seiner recht gut gestopften Pipeline wohl weit vor dem AVR die Segel streichen.
>.. "1.234567/9.876543 ganz genau ... >Klar, wenn alle Stellen signifikant sind wird der 8-bitter derzeit >verlieren Sag das doch gleich! Wenn Stellen nicht signifikant sind, lasse ich sie weg und runde entsprechend. Aber eine genaue Rechenzeit würde mich dennoch interessieren - mit voller Genauigkeit. Der STM8 scheint meines Erachtens eher für den KFZ-Bereich geplant zu sein: CAN und LIN Busse. Wer ihn braucht und damit hinkommt, bitte schön! Für allgemeine Anwendungen bietet er mir zu wenig Spielraum nach oben. Zu Preisen und Stromaufnahme: ich baue keine Batterie betriebenen Geräte. Die Leerlaufverluste der Netzteile sind in der Regel höher als die Leistungsaufnahme der µC. Ob der standby-Strom 0,1µA oder 3µA beträgt, ist mir wurscht. Beim KFZ sieht das natürlich ganz anders aus. Ob ein µC nun 1 oder 10 Euro kostet, ist mir ehrlisch gesagt bei meinen Stückzahlen egal. Die paar kEuro Preisdifferenz werden durch deutlich kürzere Entwicklungszeiten wieder eingespart. Wer höhere Stückzahlen hat, sieht das ganz anders, wird sich aber zuvor auch entsprechend kostspielige Entwicklungswerkzeuge zulegen (ICE, etc.).
@ Tropenhitze Sehe ich genau so. Beispiel: STM32F100C4. Kostet unter einem EURO. Die Palette geht in einer Linie durch bis zum STM32F107xx, mit Ethernet, USB uvm. Dass ist Felxibilität. Das ist das was im im Hobby und Beruf braucht. Mini-Chips um die Masse abdecken zu können und Leistungsfähigere derivate um mehr machen zu können, alles wird erschlagen mit einer FW-LIB, Codes müssen nur einmal etwickelt werden und können einfach kopiert und minimal angepasst werden für die neue Aufgabe. Nur darin liegt die Zukunft. Und dass macht den STM32 so genial.
>>>man braucht keinen Index, >> Für die Summation eines 100 Byte Arrays? soso. >Doch, da her er recht. Wenn's sein muss geht es auch ohne: > add a,array+0 > add a,array+1 > add a,array+2 > ... > add a,array+99 >und dabei ist der STM8 tatsächlich doppelt so schnell wie ein AVR (in >Takten) ja und u.U. sogar 3..4x so schnell als AVR (wenn Werte nicht alle hintereinander liegen), denn AVR braucht min 3 Takte (!) zum laden in Reg ! ------------------------------------------- >Und dass macht den STM32 so genial. es gibt keine EierlegendeWollMilchSau, weder STM8 noch STM32 ist eine. für complexere Anwendungen muss man wohl immer mehrere Chips haben (Bsp kleineuCs, grosseuCs, DSPs, PLDs, FPGAs)
MCUA schrieb: > ja und u.U. sogar 3..4x so schnell als AVR (wenn Werte nicht alle > hintereinander liegen), denn AVR braucht min 3 Takte (!) zum laden in > Reg ! LDS braucht 2 Takte, keine 3. Aber wollen wir hier wirklich einen Wettbewerb veranstalten, wer das hirnrissigste Problem findet, mit dem ein STM8 maximal schneller ist als ein AVR und im Gegenzug die möglich bescheuerste Anforderung, bei der ein AVR einen STM8 in Grund und Boden stampft?
>LDS braucht 2 Takte, keine 3. 3 mit laden v ind-reg oder mit LDS >Aber wollen wir hier wirklich einen Wettbewerb veranstalten, nein will keiner, aber gerade bei <<<realen>>> Anwendungen für uCs wird STM8 geg AVR um Längen voraus sein. (ich bin ja gerade wegen der etlichen 1-Takt-Befehle die diese Akku-masch nun (erstmals) bietet, darauf gestossen.
MCUA schrieb:
> 3 mit laden v ind-reg oder mit LDS
Nur die XMegas.
MCUA schrieb: >>Aber wollen wir hier wirklich einen Wettbewerb veranstalten [...] > nein will keiner, aber gerade bei <<<realen>>> Anwendungen für uCs wird > STM8 geg AVR um Längen voraus sein. Push, da dem STM8 nicht die ihm gebührende Ehre widerfährt! Iwan
Angehängte Dateien:
-
stm8s.jpeg
26 KB
Hallo, ich bin auch an so ein STM8S-Discovery Board gekommen. Da ich Linux nutze und bisher nur negatives bezüglich des USB-Anschlusses lesen konnte, waren meine Erwartungen beim ersten Anstecken an den Rechner nicht sonderlich hoch. Um so mehr wunderte es mich dann, als sich das Board schliesslich als Massenspeichergerät an meinem System anmeldete. Einen Screenshot vom Inhalt habe ich mal angehängt... Nun würde mich natürlich brennend interessieren, ob sich etwas in Richtung freier Toolchain tut/getan hat.
Inzwischen hat der freie C-Compiler sdcc (http://sdcc.sourceforge.net/) ein stm8-backend. Das wird im nächten Release, vorraussichtlich 3.4.0, enthalten sein. Bis dahin muß man halt selbst kompilieren oder die nightly snapshots verwenden. Philipp
Philipp schrieb: > Inzwischen hat der freie C-Compiler sdcc (http://sdcc.sourceforge.net/) > ein stm8-backend. Das wird im nächten Release, vorraussichtlich 3.4.0, > enthalten sein. Bis dahin muß man halt selbst kompilieren oder die > nightly snapshots verwenden. > > Philipp Das ist ja eine genial gute Nachricht, danke Philipp. Wenn der Compiler dann ähnlich gut geht wie der Cosmic, bin ich zufrieden :-)
Gerade mit dem STM8S103 und SDCC gearbeitet: Bin begeistert! Für 50 Cent, wieviel das Board kostet, bekomme ich mehr, als ich mir erwartet habe! 8K Flash, 1K RAM und 640 Byte EEPROM sind mehr als grosszügig in dieser Preisklasse. Trotz fehlender Beispiele/Projekte bekommt man den STM8 schnell auch ohne Librarys/HALs/Driver zum laufen SDCC kann man problemlos unter OS X per Homebrew installieren. Den STM8Flasher war ich zu faul anzupassen, daher habe ich im Hintergrund eine Windows-XP VM laufen zum flashen. Definitiv: A Winner!
Christopher J. schrieb: > Statt Windows-VM könntest du auch einfach stm8flash nehmen: > https://github.com/vdudouyt/stm8flash Das geht leider unter OS X nicht out-of-the-box. Irgendwas hat's da mit libusb. Unter Linux sollte es ja perfekt laufen.
Also kompiliert es einwandfrei aber läuft dann nicht? Das wäre schon seltsam. Es gibt ein paar Issues, die auf OS X bezogen sind. Von daher scheinen das ja auch ein paar Leute zu nutzen.
Hallo, es liess sich nicht kompilieren. Nachdem ich es testweise auf einem anderen Mac nach Installation von libusb kompilieren konnte, habe ich alles was mit libusb zu tun hat entfernt und erneut per brew installiert. Jetzt funktioniert es! Danke für deine Anregung.
Tja alles nur gelaber... Eine CPU ist dem Anwendungszweck nach zu wählen. Da sage ich nur... Alle sagten das geht nicht das muss eine größere CPU rein... Dann kann einer machte es einfach das das passt... Und hatte noch 50% Speicher frei... Und wusste nichts mehr damit anzufangen. Viele machen schon bei der Firmware Architektur einen großen Fehler... Sie denken wie eine Gigaherz CPU und versuchen es in einen Mikrocontroller rein zu prügeln. Dem Profi ist es egal was das für eine CPU ist. Er macht einfach seinen Job und jammert nicht über zuwenig Performance. Und wenn nicht passt wird eben das Konzept geändert das das passt.
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.