Интересно, какие грабельки еще подкинет 16-битная недо-арифметика

1. Извините, это моя ошибка. Я описывал проблему выхода из функции и не подумал, что людей могут заинтересовать совсем другие вопросы. Вы правы, конечно этот код в таком виде не откомпилируется!

Ладно, попробую ответить на ваш вопрос. Начну с проблемы LCD, поскольку, у человека, который их ни разу не использовал возникают непонятки. У всех символьных LCD имеется встроенный знакогенератор (ну как минимум мне еще не попадались симольные LCD без оного). Младшая половина знакогенератора соответствует кодам ASCII. Проблемы заложены в старшей половине. Если у вас НЕ руссифицированный LCD, то, собственно, проблемы нет, т.к. в знакогенераторе кирилицы -- нет. Если LCD руссифицированный, то возникает проблема кодировки. Дело в том, что эта кодировка не совпадает ни с 866, ни с 1251. Я так понимаю, что производитель экономил память -- там, где изображение кириллических символов совпадает с изображением латинских символов, кириллические символы выкидывались. Например, кириллическая буква Р и латинская P, О и О, Н и Н, ну и т.д. Т.е. половина кириллического алфавита оказалась расположена в латинском. Понятно, что кодировка получилась весьма веселая.

С другой стороны, поскольку мы все пишем свои проги под Виндой, то стринги в исходниках тоже имеют виндовую кодировку. Теперь если прогу откомпилировать и залить в МК, то на LCD русские сообщения исказятся до неузнаваемости. Стало быть нужно произвести перекодировку. Это можно сделать либо до компиляции, либо во время исполнения проги в МК. Поскольку, объем флешь-памяти меня не напрягал, а вывод текстовой инфы на LCD занимает очень незначительное время, я решил незаморачиваться с перекодировкой до компиляции, а выполнять ее во время вывода строк. Тем более, что в проектах могут встретиться задачи, где стринг может прийти извне, например по RS232.

Соответственно во флешь-памяти МК располагалась таблица перекодировок. Имя этой таблицы -- rus. Функция перекодировки называлась translate.

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

2. Вопрос будет посложнее. Если честно, то ахренегознаеттоваришмайор! Я могу только предполагать, что это особенность CV. Т.е. переменная data и результат функции раполагались в одном и том же регистре. Иначе говоря, если "насильственной" перекодировки не происходило, то функция возвращала то, что получала в качестве аргумента.

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


2 Nick_Shl Я обычно поднимаю все флаги на ошибки и предупреждения.

zhevak
за подробнейшие ответы.

А я не испытал серьёзных неудобств с асмовыми вставками в IARе.
(Дальнейшее к Вам Сергей не относится, так как Вы всё это знаете лучше меня, это больше для delamoure и других, выбирающих инструмент)

Начнём с того, что IAR позволяет использовать inline ассемблер. В том числе и с многострочными конструкциями.
Во-вторых он позволяет писать на ассемблере законченные процедуры и подключать на этапе линковки. Это на мой взгляд намного правильнее и логичнее. Прога получается значительно нагляднее и завершённее. Использование регистров компилятором детально описано, и при таком варианте я не заметил ухудшения работы оптимизатора. (А inline ассемблер не применял, по причине вышеописанной)
Во втором варианте возможно использовать общие символические имена. Причём я работал со структурами, массивами, флагами именно с символьными именами.

Несколько напрягает в IARе перевод всех символьных имён в регистры и константы десятичные. И это перед выдачей листинга.
Ну например исходный текст
int i=1234;
В распечатке асмового листинга мы увидим что-то типа
ldi r26,210
ldi r27,4
Я бы предпочёл увидеть что-нибудь типа
ldi R26,low(1234)
ldi R27,high(1234)
Аналогично и с именами символическими. Хотя наверное это брюзжание.

Впрочем, IAR для меня не новость
"Многострочные конструкции inline ассемблера" вызывают оторопь: "where \n (new line) separates each new assembler instruction". И это удобно?
На этапе линковки свой ассемблерный код не подключал. Коллега мне демонстрировал как это делается еще года 3 назад. Также способ описан в инете, по-моему, кем-то из местных (Сергеем Борщом?). Показалось неудобно, долго. Когда код писать? Тут целый обряд с бубном протанцевать необходимо.

Это очень спорный момент. Ассемблерные вставки обычно делаются для повышения быстродействия. Использование написанных на ассемблере законченных процедур однозначно порушит стратегию оптимизатора и вместо выигрыша по времени можно получить проигрыш. Особенно если ассемблерная функция маленькая и быстрая. Тут может быть и большой оверхед - регистровые переменные в стек, рабочие копии обычных сохранить по "месту прописки". По выходу из ассемблерной функции все проделать в обратном порядке. А ведь бедный ИАР не знает, что в этой внешней процедуре происходит с регистрами, вот и сохранит по максимуму. У GCC видимо при такой методике включения S файлов должны быть похожие трудности. А вот инлайн ассемблер у GCC выше всяких похвал. Именно его использование и позволяет достичь максимального быстродействия - в этом случае накладных расходов или вообще нет, или они малы. А в отдельных файлах удобно обработчики прерываний делать.

А вот я уже привык ибо влом перелопачивать старые проекты под gcc... CV всегда под рукой...
просто надо знать в каких случаях если справа у одного из операндов стоит младший тип и производится умножение/сложение/сдвиг что будет с результом ...
например умножать char на int некорректно, а наоборот- можно
но вообще-то всегда варнинги генерятся их надо внимательно читать и все будет ок.

"Асмовые вставки" == inline assembler. Они, как правильно заметил Qwertty, хороши именно тем, что не надо тратить время на сохранение регистров и вызов функции. При этом gcc позволяет в такой вставке сделать все, что угодно, а ИАР в документации честно пишет:

а как можно преобразовать строки для вывода на LCD на этапе компиляции? так, чтобы в исходном тексте они были в первозданном виде, а в объектном файле - уже перекодированные?
понимаю, что надо как-то влезть в последовательность работы препроцессора, но как?

Написать программу, которая из файла lcd.c делает _lcd.c перекодируя символы между одинарными и двойными кавычками. Компилятору скармливать _lcd.c. В случае gcc такая программа может выдавать результат в поток вывода а компилятор может принимать входные данные через поток ввода.

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

Я не совсем точно выразился. Имел ввиду, что у программы (в общем смыле) имеются несколько этапов жизни (или как это правильно сказать?). Этап разработки, написания теста, компиляция -- это все есть первый этап. Второй этап -- это, собственно, работа бинарного модуля в изделии, ран-тайм. Первый этап я условно назвал -- "на этапе компиляции". Что, видимо, и внесло путаницу в понимание.

На самом деле, вряд-ли кто осмелиться "отхачить" компилятор так чтобы тот "на этапе компиляции" (в буквальном смысле) конвертировал кодировку стрингов.

Мою фразу "преобразовать строки для вывода на LCD на этапе компиляции" следует понимать так: на этапе написания исходных текстов вы должны стринги набирать как они есть -- в Виндовой кодировке. Вы ведь все равно будете компилировать прогу не один раз, пока не исправите все ошибки. И вам, скорее всего, понадобится видеть читаемые строки. А когда ошибки будут устранены (т.е. перед окончательной (последней) компиляцией, сборкой), вы должны или руками, или с помощью самопальной проги-конвертора, найти стринги и заменить в них символы на нужную кодировку.

Когда стрингов не так много, это быстрее сделать руками по табличке-шпаргалке. Когда же проект достаточно большой и развесистый, то проще написать утилиту, которая будет выискивать в тексте скармливаемых ей файлов стринги и заменять в них байты. Кроме того, надо учитывать, что конвертации могут подвергаться не только стринги, а и одиночные символы. Т.е. проблема еще та!

ЗЫ
1. Сергей Борщ немного раньше ответил.
2. Еще раз хочу напомнить, что стринги и символы могут приходить из внешнего мира. Т.е. задачу перекодировки удобнее решать на этапе ран-тайм, непосредственно в драйвере LCD. В этом случае вообще никаких проблем не будет. Единственная неудобство -- это незначительное снижение быстродействия при выводе и небольшое увеличение кода программы. Но поскольку, доля времени на перекодировку соизмерима или даже меньше, чем время на дергание лапок у LCD, а поток выводимой на LCD информации вообще никакой, то практически перекодировка в режиме ран-тайм не оказывает никакого торможения.

Сообщение отредактировал zhevak - Dec 4 2008, 10:37

Существуют индикаторы с 1251 кодировкой (как одной из возможных). Делает фирма МЭЛТ.

utils/bin/sed.exe
Просто научиться готовить -

да. Спасибо.

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