FAQ по STM8

[st_1]

Поделил частоту на 2 - все замигало. 20 мег на процессоре всеж выше 16 и наверное можно еще повысить. Но, главное, на таймерах и всей переферии осталось 40 мег. Т.е. разрядность ШИМ повышается, что для маломощных SMPS весьма полезно. Да и для интерфейсов тоже часто скорости не хватает.

Сомнительная польза...
Вырастет потребление, что-то куда-то начнёт пролазить, что-то сбоить... температурный диапазон... диапазон питающих...
Как-то не по даташиту... но для настольных комнатотемпературных решений прокатит... не в серию...

[tanq]

Понятно, в серию разогнанные процы лучше не запускать.

По Космику небольшое дополнение: как выяснилось он не умеет нормально умножать числа. Перемножение 16x16-›32 выржается в нем в вызове специальной функции умножения, а потом еще и функции 32битного сложения. Интересно, что разработчики этого компилятора довольно высоко оценивают свою разработку, если судить по ее цене

Ждем портирования GCC. С этим хламом далеко не уедешь.

[zheleznjakov]

во-первых, по умолчанию не сделана инициализация глобальных переменных
во-вторых, там задается начало стека и его надо исправлять в зависимости от объема SRAM.

По умолчанию где? У меня все нормально, но я пишу скрипт свой.
Про стек аналогично.
Про умножение, ни кто собственно и не скрывал, в доке на компилятор все расписано подробно.
У stm8 на сколько я помню нет аппаратного умножения 16*16.
32 кб = 0$, вроде не дорого

[tanq]

zheleznjakov
По умочанию - это в скрипте из прилагаемого примера. С уможением мне не нравится то, что компилятор его не инлайнит. Это во первых. Во-вторых, насколько я понял, вместо умножения 16x16-›32 делается преобразование в long и потом умножение 32x32-›32, что намного дольше. 32 битные сложения тоже не инлайнит. Может я каие-то опции пока не нашел?

Но зато я этот космик к code::blocks приделал

[qwerky]

Ждем портирования GCC. С этим хламом далеко не уедешь.

это вряд ли... Всякие Космики и ИАРы хотят зарабатывать - наверняка забашляли ST чтобы не допустить появления свободного компилятора. Остается надеятся на энтузиастов opensource, как было с AVR-GCC

[tanq]

А как они это могут не допустить? Я не вижу возможных инструментов. SDCC уже портировали, только сыроват он.

[zheleznjakov]

zheleznjakov
По умочанию - это в скрипте из прилагаемого примера. С уможением мне не нравится то, что компилятор его не инлайнит. Это во первых. Во-вторых, насколько я понял, вместо умножения 16x16-›32 делается преобразование в long и потом умножение 32x32-›32, что намного дольше. 32 битные сложения тоже не инлайнит. Может я каие-то опции пока не нашел?

Но зато я этот космик к code::blocks приделал

Если бы точно знать что функция будет один раз использоваться, конечно можно было и не делать вызов, иначе простая экономия памяти.
Честно говоря пока в подробности умножения не в давался, но на заметку поставил гляну потом что да как. (не думаю что imul и lmul физически одна и та же функция)
(интересно бы гянуть как с этим в ИАРе? за который просят по более)
Коде:блок я не перевариваю, прикрутил его к эклипсу.
Меня вот больше волнует, но пока я не разбирался, как перенести часть этих функций в ОЗУ.

[tanq]

Еще интересный вопрос появился. Можно ли в STM8 обращаться к регистрам в 16 битном режиме? В хидерах они объявлены как 8-битные, но я ведь могу и подправить хидеры, сделав для каждого регистра union. Считывание АЦП по байтам выглядит маразматично. В то же время 16 битный регистр вообще не считывается, а сразу используется по назначению (в вычислениях).

[zheleznjakov]

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

Опять, таки все это описано в доке

[tanq]

Короче, надо попробовать. А точно ldw читает байты в неправильном порядке? Я как понял проц low-endian, т.е. байты идут старший, потом младший.