Форум РадиоКот

ОК, вечером посмотрю ссылку.
А сравнивают их в МИПСах, ДМИПС для ARMов.
Да и собственно в мипсах в даташите написано для avr 1MIPS/MHz и до 20 MIPS при 20МГЦ
для STM8 20MIPS/24MHz если память не подводит.

А вот есть и драйстоун http://bsvi.ru/obzor-stm8/
пишут, что stm ки аж на 20 а то и до 30% быстрее avr

Это как "порошок теперь чистит на 30% лучше".

Это идеальные МИПСы, к реальности они имеют чисто справочное отношение.
В действительности у АВРки большая часть комманд имеет длительность 1 цикл. но это надо упереться и не использовать переходы, тоже и у СТМ8,
Сегодня подборку забирал для монтажниц,купил несколько процессоров для себя на опыты (есть почти вся линейка дисковери , но нужны для работы разработчиков)
STM8S003 - 1 шт
STM8S103 - 3 шт
STM8L101 - 2 шт

Panda_Y2K писал(а): пишут, что stm ки аж на 20 а то и до 30% быстрее avr

Написать то и я смогу, главное как проверялось, я так считаю.

Идеальные мипсы написаны в даташите - это они имеют чисто справочное значение.
Я привел ссылочку, как просили, так что вопрос к автору.
Кроме того Dhrystone - Результатом теста является Dhrystones per second (количество итераций основного цикла в секунду).

Тесты Whetstone и Dhrystone являются синтетическими, то есть простыми программами, выдерживающие определенные соотношения между различными типами инструкций.
http://ru.wikipedia.org/wiki/Dhrystone
Этот тест собственно является мерилом, имеет определенную схему тестирования и вменяемый результат, и если написали, что проводили Dhrystone не вижу причин не доверять.
В реальной программе, тем более на разных приложениях процы могут показать себя сильно по разному, но есть мнение, что stm быстрее работает в случае если требуется часто и много переключаться между контекстами, за счет отсутствия необходимости сохранять регистры в стек, хотя ИМХО все зависит от компилятора, т.к. где то видел, что космик локальные переменные в стек сует, что собственно редьки не слаще. Опять же что лучше? - вопрос, ибо у avr двух уровневый конвеер и 4 такта на вхождение в прерывание, а у stm 3х уровневый конвеер и 5-9 тактов и хрен понятное время от этого, не возможно (сложно) все посчитать по тактам ибо конвеер... который к тому же в отладке сбрасывается... так, что бубен субъективной оценки в студию .

У меня вопрос не к википедии, а к БСВИ, который просто утверждает, без проведения теста, т.е. голословно.

Какие есть мерятели скорости я и без вики знаю

Panda_Y2K писал(а):В реальной программе, тем более на разных приложениях процы могут показать себя сильно по разному, но есть мнение, что stm быстрее работает в случае если требуется часто и много переключаться между контекстами, за счет отсутствия необходимости сохранять регистры в стек, хотя ИМХО все зависит от компилятора, т.к. где то видел, что космик локальные переменные в стек сует, что собственно редьки не слаще. Опять же что лучше? - вопрос, ибо у avr двух уровневый конвеер и 4 такта на вхождение в прерывание, а у stm 3х уровневый конвеер и 5-9 тактов и хрен понятное время от этого, не возможно (сложно) все посчитать по тактам ибо конвеер... который к тому же в отладке сбрасывается... так, что бубен субъективной оценки в студию

вот, поэтому, я хочу, именно на конкретной задаче провести сравнительный анализ, заодно, понять, этот жуткий ассемблер
Ибо дринстоны - это такая задача, которая в повседневной жизни не встречается и имеет чисто синтетическое происхождение.

Если по существу - меня больше плотность кода волнует, т.к. современных контроллеров хватает на практически любую задачу (не связанную с обработкой сигналов).

например, пик16 один и то тоже проект занимает чуть более 6 килобайт, авр 1960 байт, STM8 пока не ясно, проект не перевел, ибо C у космика какой то особый.

ИМХО это можно определить и так, при нормальном компиляторе размер кода будет примерно как у avr плюс минус чуть.
У пиков сокращенный набор команд около 30 стало быть код будет большим, у avr порядка 120-130, код маленький, у stm8 - 96.
За счет того, что у него архитектура чуть отличается от avr отсутствием РОН чуть меньше команд связанных с этим моментом, в
целом получится практически тоже самое.

проект перекину, в ближайший месяц посмотрим, что получиться.

есть примеры ассма для стм8 вразумительные, типа складываем два Integer и тп и тд?

Panda_Y2K писал(а): пишут, что stm ки аж на 20 а то и до 30% быстрее avr

в доке встречал такое: 20 мипс на 24 мгц.

Нашел

STM8S Mainstream series

ST’s STM8S series of mainstream 8-bit microcontrollers covers a large variety of applications in the industrial, consumer and computer markets, particularly where large volumes are concerned. Based on the STM8 proprietary core, the STM8S series benefits from ST's 130 nm technology and advanced core architecture performing up to 20 MIPS at 24 MHz. Embedded EEPROM, RC oscillators and a full set of standard peripherals provide a robust and reliable solution for designers.

У AVR 20 мипс на 20 мгц

я это в первом посте на этой странице писал.

Эти Integer-ы что посчитаны в MIPS - 32-битные у ARM и 8-битные у STM8

Panda_Y2K писал(а):я это в первом посте

Всё верно, просто не понятно как БСВИ измерял.

Если у смт 24 мгц и 20 мипс, у авр 20 мгц и 20 мипс,
о каких 30% речь? меня клинит на этой цифре

каждый месяц уходит по сотне изделий с аврками, грубо говоря 2000 рублей в месяц "выгоды" и 24 тысячи в год при переходе на стм, но проц юзается во всю, всё что можно было выжать, выжато.

Найдено на просторах
http://bbs.21ic.com/icview-171836-1-1.html

IARAVR:
总代码量： 1 582 bytes of CODE memory (+ 84 range fill )
执行时间：37240874时钟周期（软仿真）


IARSTM8:
总代码量： 1 369 bytes of readonly code memory
执行时间：36170907时钟周期（软仿真）


вот ещё http://www.chibios.org/dokuwiki/doku.ph ... os:metrics

Из них два интересных файлика:
http://chibios.sourceforge.net/reports/ATmega128-16.txt
http://chibios.sourceforge.net/reports/ ... onance.txt

Ну, что ж нормально, как и ожидалось переключение контекста у stm быстрее аж на 2мкс
За счет линейного адресного пространства я думаю не будет геморроя с указателями.
Объем программы даже меньше получился чем у авр, но не сильно.

Да, я тоже на это посматривал. Но компиляторы далеко вперёд продвинулись.

Сделал сводную табличку из двух файлов на тот момент.

Большее быстродействие выделил цветом.

Большее быстродействие у STM8 в:
1. --- Test Case 11.4 (Benchmark, context switch) --- Score : 107368 ctxswc/S
2. --- Test Case 11.6 (Benchmark, threads, create only) --- Score : 27276 threads/S
3. --- Test Case 11.12 (Benchmark, mutexes lock/unlock) --- Score : 123188 lock+unlock/S

Большее быстродействие у AVR
Во всех остальных 9 тестах.

Смотрите приложенный файл.

Как положено переключение контекста рулит и создание потоков.
Сильно НЕ порадовали прерывания и таймеры.
Судя по всему на них хорошо будет гонять какую нибудь РТОС.

Кроме переключения есть еще и тело задачи )

тем более тест лохматых годов.

Да какая разница каких годов, он же со временем не меняется, а новый тест от этого лучше не покажет.
В основном цикле разницы большой вроде небыло, а переключений между задачами много, так, что выигрыш должен быть существенный.

Все эти тесты от лукавого...
Восьмибитки они и есть восьмибитки... +- лапоть... давно всё уже пережёвывалось и выплёвывалось...
У STM8 богаче периферия...особенно у STM8L... Поэтому юзание STM8, с учётом периферии, даст лучший конечый результат...

HHIMERA писал(а):Все эти тесты от лукавого...
Восьмибитки они и есть восьмибитки... +- лапоть... давно всё уже пережёвывалось и выплёвывалось...

Приветствую В принципе, согласен. Я вообще считаю, что 8биткам шибкое быстродействие не нужно.

HHIMERA писал(а):У STM8 богаче периферия...особенно у STM8L... Поэтому юзание STM8

Может быть так оно и есть. В нескольких проектах стоит лысый 2313 - кроме таймера, например, ничего не используется, при нехватке этой самой переферии можно её заэмулировать, как у Юбикома.
В другом проекте стоит STM8S юзается только из за объема ОЗУ и I2C, хотя последний можно было бы заэмулировать, если надо.

Проект перекинул, остались только машинно специфичные моменты.

В нескольких проектах стоит лысый 2313

Дык... вместо 2313 можно купить две STM8S003F3... отладиться в STM8S103, а готовое зашить в STM8S003...
В STM8L многие мелкие дисплеи можно уже мутить хардварно... что существенно уменьшает размер кода...
Т.е. если не нужно высчитывать каждый такт и корпеть над каждым ногодрыгом, то STM8 самое оно...
Но самое интересное - схожесть периферии STM8 с STM32... что очень облегчает перенос кусков кода...
Даже если небольшой перерасход памяти и присутствует, то это неважно... память сильно дешевеет... а если не хватает скорости, то переход на STM32 уже неизбежен...