www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Empfehlung 8-Bit-Controller: STM8


Autor: Иван S. (ivan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Иван S. (ivan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Иван S. schrieb:
> nachdem ich gerade geistig aus der Palmsonntagsmesse gekommen bin

Sorry, natürlich kam ich nicht "geistig" aus der Messe sondern geistig 
aufgefrischt.

Autor: G4st (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab hier auch noch nen STM8S-Discovery von der Embedded-world 
rumliegen; leider sieht's mit ner linux-toolchain recht mau aus :(

Autor: Sebastian B. (mircobolle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Иван S. (ivan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Иван S. (ivan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Tropenhitze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Olaf

Kann es sein, dass Du Probleme mit UART6 hast? Oder ist Olaf K. ein 
anderer? :-)

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Tropenhitze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>...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/r...
Wenn da ein E10a dabei ist, wäre das ein guter Preis für Beides.

Autor: thorstendb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Иван 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 :-)

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Иван S. (ivan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Иван 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

Autor: Marius S. (lupin) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Als assembler kann ich vasm empfehlen, den portiere ich auch gerade. 
Sollte schon möglich sein auch einen STM8 port zu erstellen.

Autor: Иван S. (ivan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/List...

Iwan

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Tropenhitze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Иван S. (ivan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Иван 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

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Иван 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.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> '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

Autor: Tropenhitze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Иван 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
:-)

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
--------------------

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
(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

Autor: Иван S. (ivan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Иван S. (ivan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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?

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Spess:

So wie ich es verstanden habe hatte er nach 8051-Typen geschaut.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

OK. Ich habe es gesehen.

MfG Spess

Autor: ST (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Иван S. schrieb:
> Es ging aber um 8051er.

Dann gugg mal bei ST selber: uPSD32XX

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
--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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Relegionskriege liegen ja seit je her im Trend, nicht nur zu Ostern . . 
. ;-)
Amen!

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Иван 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. ;-)

Autor: Иван S. (ivan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Hoffnung stirbt zuletzt ;-)

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Иван 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...)

Autor: Tropenhitze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Solche Zahlen werden doch so gerechnet:
Beitrag "Re: SHT11, Abweichung bei Temperatur"
(ohne float)

Autor: Tropenhitze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Иван S. (ivan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Иван 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
uint8_t array[100];
uint16_t res = 0;
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...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Иван 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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: Иван S. (ivan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
>
> uint8_t array[100];
> uint16_t res = 0;
> 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...

Kann man auf dem Achtbitter genauso schnell implementieren wie auf dem 
16bitter. 8 bit ist die Zukunft!

Iwan

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Иван 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

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Иван 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.

Autor: Иван S. (ivan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
> uint8_t array[100];
> uint16_t res = 0;
> 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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Иван 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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Иван 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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Иван S. (ivan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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".

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Иван 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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Иван 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? ;-)

Autor: Иван S. (ivan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Иван 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

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Soviel zum Thema reale Anwendungsleistung . . .

Der akademische Elfenbeinturm ist schon sehr kuschelig, schon klar.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tropenhitze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>.. "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.).

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>>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)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MCUA schrieb:

>   3 mit laden v ind-reg oder mit LDS

Nur die XMegas.

Autor: Иван S. (ivan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Herbert (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Philipp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Phantomix Ximotnahp (phantomix) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.