STM8(S/L), первые впечатления

[kison]

Я детально не вникал глунял просто распределение секций у линкера, при 2048 байт озу нулевая страница 255 байт, а bss (data) от 0x0100 до 0x05FE, вот и подумал что 512 под стек.

Вообще обычно все не так. Задается область памяти в скрипте линкера и указывается какие секции туда складывать. Соответственно размеров у секций нет, есть только у всей области. Тут либо поместится, либо нет.
У космика почему то секции имеют отличный от стандартного смысл. bss - секция для переменных инициализируемых 0 у всех, кроме космика. У космика это почему то no_init. А инициализируемые нулем складываются в ubsct. Причем проблема только с секцией ubsct - если массивы явно проинициализировать, то все собирается без всяких шаманских действий.

[kison]

а прога "соберается" да же если ARRAY_SIZE 20000 тыщ поставить...

ARRAY_SIZE 1000

#error clnk Debug\test_for_kazus.lkf:1 segment .bss size overflow (190)

Хотя с 500 - собирается. Похоже в скрипте линкера RAM задана для толстых кристаллов с ОЗУ›2кБ

А скрипта то и нету. Все через командную строку задается. Причем все равно какой кристалл - она одинаковая. Вот и ответ - переполнение отслеживается только если в самый толстый кристалл не влезает.
ЗЫ. Хочу GCC под STM8... Очень сильно хочу...

[EugVor]

Ну для тех кто все еще сомневается в быстродействии STM8 еще небольшой пример.
Один из распостраненных приемов построения программ - вечный цикл с вызовом действий по флажкам. Флажки соответственно удобно делать в виде битовых полей структуры. Ес-но с квалификатором volatile, ведь они устанавливаются вне основного цикла.
В результате на архитектурах с организацией ReadModifyWrite, а именно такая у АВР, изменять состояние этих флажков приходится при запрещенных прерываниях. Типичный листинг:

Код:

cli LDS R16,adress andi R16,mask sts adress,R16 sei

STM8 справляется с этим без запрета прерываний, причем одной однотактовой командой - bres. Выходит аж в 7 раз быстрее Реально то это конечно не так важно, обычно при такой организации запасы по времени большие. Но все же.

Тут соль в том, что это атомарная операция, в которую не сможет вклиниться процесс из какого-нибудь обработчика? Это весьма пользительное свойство. Если бы ещё была возможность декрементировать и сбрасывать за 1 такт, тогда можно было бы безопасно останавливать программные таймеры из прерываний хотя бы однобайтовые.

Кстати кто что думает про ST7FOX - самая маленькая имеет 2к флеши, АЦП, ШИМ и стоит чуть дороже таймера 555 ($0.15)?

- Дайте мне ST7FOX-ов.
- Вам сколько?
- Грамм 200-300 не больше, плз

[kison]

Тут соль в том, что это атомарная операция, в которую не сможет вклиниться процесс из какого-нибудь обработчика?

Да, соль в этом.

Если бы ещё была возможность декрементировать и сбрасывать за 1 такт, тогда можно было бы безопасно останавливать программные таймеры из прерываний хотя бы однобайтовые.

Я не понял. Можно на примере?

[EugVor]

Я не понял. Можно на примере?

Чтобы отмерить задержку на ожидание байта из UART кратную 10мс, например 500мс, я записываю в tmr=50; и в 10мс-ом обработчике:

if (tmr) tmr --; // Если взведён, декрементировать;
if (!tmr) {UartErr=1;} // Если успел досчитать до нуля...;

в обработчике по приёму UART:

 tmr=0; // Остановить таймер.

– эта операция может вклиниться в декремент tmr --; особенно если он не однобайтовый. Как правило это заканчивается тем, что таймер продолжает отсчитываться дальше и фиксирует ошибку.

[kison]

Как правило это заканчивается тем

Как правило такие таймеры обсчитываются уже внутри обработчика. Так что UART просто подождет. Я обычно не по значению счетчика работаю, а имею еще флажки включен/выключен, циклический/однократный. И именно флажок "включен" сбрасываю, если таймер мне больше не нужен. Также по нему ориентируюсь - работает сейчас таймер или нет. Просто таймеры могут и циклическими быть, так что если счетчик == 0, это не значит что таймер выключен. Заодно так еще и быстрее выходит - модифицируется всего один байт. Счетчик при этом может быть хоть 32 битный.

[EugVor]

Я тоже к такому решению пришёл в обработчике УАРТ просто установить признак, что считать дальше не нужно и проверять его вместо проверки значения таймера, но это на каждый таймер ещё доп. проверки, а таймеров уже самих по себе немеряно и обработчик уже разросся, при прерываниях каждую 1мс начинает утыкаться лицом себе же в зад.
Ну, это уже всё это конечно конкретные вопросы и не совсем по теме

[kison]

но это на каждый таймер ещё доп. проверки

Ровно то же что и if (tmr) tmr --; Проверка то все равно есть. А если счетчик не 8 бит, то проверка будет даже быстрее.

Что то пробую на асме что изобрести, типа DDS из 200 сообщения. Но пока он совсем незнакомый. Выходит у меня 13 тактов. Пока. Думается что можно и побыстрее...

[EugVor]

Ровно то же что и if (tmr) tmr --; Проверка то все равно есть. А если счетчик не 8 бит, то проверка будет даже быстрее.

Что то пробую на асме что изобрести, типа DDS из 200 сообщения. Но пока он совсем незнакомый. Выходит у меня 13 тактов. Пока. Думается что можно и побыстрее...

Да, но вот если бы был возможен атомарный декремент, то инициализацию tmp можно было бы делать в обработчиках, например на ожидание ответа при отправке последнего байта сообщения, а не протаскивать её через фон с отключенными прерываниями. Это вроде попроще.

[=GM=]

Что то пробую на асме что изобрести, типа DDS из 200 сообщения. Но пока он совсем незнакомый. Выходит у меня 13 тактов.

Взглянуть можно на 13-ти тактовый вариант?