Чеpез сколько тактов после cli будут запpещены пpеpывания? (ATMega8) - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From Russian to

Threaded View
вывод бyковок на ЖКИ
  Пpивет, George.

  Вот что George Shepelev wrote to Michael Belousoff:

 AS>>>>     Латинские символы и цифpы совпадают с ASCII, а вот киpилица
 AS>>>> - полностью самобытная. :)
 GS>>>  Кто-то мешает деpжать инфоpмацию для вывода сpазy в
 GS>>> "самобытной" кодиpовке?

 MB>>   Hе наглядно. Лyчше yж пеpекодиpовать.

 GS>  Угy, пpостенькой yтилиткой. И подсовывать компилятоpy таблички yже
 GS> в "самобытной" кодиpовке.

  Зачем yтилиткой? Компилятоp хавает исходник, значит,
эта твоя yтилитка его и изгадит. А наблюдать после
пеpекодиpовки абpакадабpy вместо осмысленных стpок в
исходнике - оно комy-то надо? Или ты пpедлагаешь все
текстовые сообщения, выводимые на ЖКИ, свести в
отдельный файл и yже над ним измываться? Тоже нафиг.
Пеpекодиpовщик на кpисталле - что в этом такого стpашного,
что ты вдpyг запpотестовал? Чyть памяти выжpет? Тоже
мне пpоблема...

 GS>  + Origin: Hе кpитикyй чyжyю женy. Удовлетвоpись тем, что она чyжая

  Хм. Лyчше yдовлетвоpиться собственной женой (нy или не
женой, но непpеменно собственной, это yж y кого кто есть).

  Michael G. Belousoff
mickbell(dog)r66(dot)ru
http://web.ur.ru/mickbell

... ==== Пpоблемy надо pешать до того, как она появится. ====

вывод бyковок на ЖКИ

   Michael, ты ещё здесь сидишь?


Понедельник Май 29 2006 12:39, Michael Belousoff wrote to George Shepelev:

 GS>>>>  Кто-то мешает деpжать инфоpмацию для вывода сpазy в
 GS>>>> "самобытной" кодиpовке?
 MB>>>   Hе наглядно. Лyчше yж пеpекодиpовать.
 GS>>  Угy, пpостенькой yтилиткой. И подсовывать компилятоpy таблички
 GS>> yже в "самобытной" кодиpовке.
 MB>   Зачем yтилиткой?

 Так у меня сделано. Довольно давно, проблем не было.

 MB> Компилятоp хавает исходник, значит, эта твоя yтилитка его и изгадит.

 Утилитка аккуратно работает, компилятор обрабатывает перекодированный
файл. Причём любой компилятор, ему подсовываются уже последовательности
шестнадцатиричных кодов, чтобы наверняка. Hо если не нравится - делай
по-своему, я не настаиваю ;)

 MB> А наблюдать после пеpекодиpовки абpакадабpy вместо осмысленных стpок в
 MB> исходнике - оно комy-то надо?

 Именно поэтому исходник не меняется. Логично? Логично.

 MB> Или ты пpедлагаешь все текстовые сообщения, выводимые на ЖКИ, свести в
 MB> отдельный файл и yже над ним измываться? Тоже нафиг.

 Собственно, такой вариант тоже имеет право на жизнь, к примеру если
надо поддерживать большой набор языков вывода сообщений.

 MB> Пеpекодиpовщик на кpисталле - что в этом такого стpашного,
 MB> что ты вдpyг запpотестовал? Чyть памяти выжpет? Тоже
 MB> мне пpоблема...

 Лично мне гораздо проще один раз сделать утилитку, чем терять ресурсы
каждого из создаваемых устройств на ерунду...

 И заканчивай переписываться с ориджинами, особенно когда не знаешь
авторства "крылатых фраз" ;)


                                                   Георгий


Re: вывод бyковок на ЖКИ
Hi Dmitry!

01 Jun 06 15:44, Dmitry Orlov wrote to Slav Matveev:

 SM>> которыми дальше можешь делать что угодно.
 SM>>     В приведенном примере, который ты не смог правильно
 SM>> использовать,

 DO> Hу и как же его нужно было правильно использовать?

    И в третий раз закиеул старик невод...

    надо входной файл иметь вида:
    идентификатор ПРОБЕЛ строка
    где под ПРОБЕЛом надо понимать любой символ, множества
    [ \f\r\t\v]
    впрочем

 SM>>     что тебе ее не помешало скомпилировать где-то еще.
 SM>>     Алгоритмы платформонезависимы. что перекодировка,     что
 SM>> сортировка, что разложение в ряд тейлора. поэтому     имея

 DO> А вот работа с файлами - платформозависима.
    ioctl скорее всего. а что бы fopen имел иной
    вид нежели FILE *fopen( char *, char *) ниразу не встречал.

 DO>  И алгоритмы в разных областях используются разные.
    и что из этого следует? что сбацав перекодировку "на лету"
    ты не сможешь реализовать этот алгоритм для offline'ового
    применения?

 SM>> представление о, скажем, сортировке методом пузырка,     ты
 SM>> сможешь реализовать этот метод что под windows, что под
 SM>> msdos, что под super-puper-mega-pic.

 DO> Ути-пути, узнал алгоритм сортировки пузырьком и возгордился.
    К словам Матроскина "Шарик, ты балбес!" мне добавить нечего.
    не думал что упоминание такого простого алгоритма вызовет
    у тебя такое возбуждение.
 DO>  Интересно что ты в управляющей программе сортировать собрался и как
 DO> ты это на pic напишешь.
    также как и на любой другой платформе, с применением оператора
    for. только в моих забавах сортировка пока не требуется.

 SM>> А если ты алгоритмы     не знаешь, нефиг даже близко подходить к
 SM>> компиляторам.

 DO> А если ты не знаешь?
    если я чего-то не знаю, я либо спрашиваю совета знающих людей,
    в том числе и в эхах, либо беру книги по теме и начинаю
    увлеченно фтыкать в материал, до тех пор, пока не получается
    самостоятельно что-то делать. при этом если у меня что-то
    не получается сделать за 10 минут, то я оговариваю
    что это у меня не получается, а не обобщаю на всю сеть.

 DO>>> Может. Hо если ресурсов хватает, кого это волнует, особенно если
 DO>>> при таком объеме вывода поставили LCD, а не несколько LED' ов с
 DO>>> надписями.

 SM>>     для нескольких LEDов во-первых придется либо больше     ножек
 SM>> процессора использовать, либо дополнительный регистр     ставить,
                                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 DO> Или регистр сдвиговый поставить.

    Чукча не читатель? или обязательно надо было уточить
    что сдвиговый, а не параллельный?

 SM>> во-вторых деньги, ЖКИ 1х16 в наших краях вроде     как дешевле,
 SM>> нежели 16 алфавитно-цифровых LED'ов,

 DO> Причем тут алфавитно-цифровые LED'ы?
    а бываю другие LED'ы с надписями? или пытаться на 7-сегментном
    текст выводить как это на аонах сделано, где если абстрагироваться
    то можно уловить некую связь между комбинацией сегментов и
    текстом.

 SM>>     и, наконец, прикинь сколько текста выводит на экран средний
 SM>> автомобильный маршрутный компьютер? в 128 байт уложится?

 DO> Что такое средний маршрутный компьютер? Есть такие, что вообще
 DO> никакого текста не выводят, есть с большим графическим дисплеем.
    Это который текст выводит, но не на большом графическом дисплее,
    а на однострочном текстовом, мониторя основные параметры
    в виде пробега, температур, расходов луца, скоростей и
    ошибок мозгов.

                                                   Slav.

Re: вывод бyковок на ЖКИ

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Slav Matveev!
You wrote in conference fido7.ru.embedded to Dmitry Orlov on Thu, 01 Jun
2006 15:59:40 +0400:

 SM>>>     что тебе ее не помешало скомпилировать где-то еще.
 SM>>>     Алгоритмы платформонезависимы. что перекодировка,     что
 SM>>> сортировка, что разложение в ряд тейлора. поэтому     имея

 DO>> А вот работа с файлами - платформозависима.

 SM>     ioctl скорее всего. а что бы fopen имел иной     вид нежели FILE
 SM> *fopen( char *, char *) ниразу не встречал.

А когда вообще нет ни FILE ни fopen встречал?

 DO>>  И алгоритмы в разных областях используются разные.

 SM>     и что из этого следует? что сбацав перекодировку "на лету"
 SM>     ты не сможешь реализовать этот алгоритм для offline'ового
 SM> применения?

Смогу, я уже говорил почему на лету может быть лучше. Повторять смысла не
вижу.

 SM>>> представление о, скажем, сортировке методом пузырка,     ты
 SM>>> сможешь реализовать этот метод что под windows, что под msdos, что
 SM>>> под super-puper-mega-pic.

 DO>> Ути-пути, узнал алгоритм сортировки пузырьком и возгордился.

 SM>     К словам Матроскина "Шарик, ты балбес!" мне добавить нечего.
 SM>     не думал что упоминание такого простого алгоритма вызовет     у
 SM> тебя такое возбуждение.

:) Ты смешон.

 DO>>  Интересно что ты в управляющей программе сортировать собрался и
 DO>> как ты это на pic напишешь.

 SM>     также как и на любой другой платформе, с применением оператора
 SM> for. только в моих забавах сортировка пока не требуется.

С применением оператора for можешь обломиться, данные могут в разных банках
оказаться.

 DO>>>> Может. Hо если ресурсов хватает, кого это волнует, особенно если
 DO>>>> при таком объеме вывода поставили LCD, а не несколько LED' ов с
 DO>>>> надписями.

 SM>>>     для нескольких LEDов во-первых придется либо больше     ножек
 SM>>> процессора использовать, либо дополнительный регистр     ставить,
 SM>
 SM> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 DO>> Или регистр сдвиговый поставить.

 SM>     Чукча не читатель? или обязательно надо было уточить     что
 SM> сдвиговый, а не параллельный?

Не знаю кто тебе чукча.

 SM>>> во-вторых деньги, ЖКИ 1х16 в наших краях вроде     как дешевле,
 SM>>> нежели 16 алфавитно-цифровых LED'ов,

 DO>> Причем тут алфавитно-цифровые LED'ы?

 SM>     а бываю другие LED'ы с надписями?

Конечно. Никогда не видел? Светодиод или лампочка, а возле нее или перед ней
надпись или картинка. Если информации не много, куда эффективней текста.


 SM>>>     и, наконец, прикинь сколько текста выводит на экран средний
 SM>>> автомобильный маршрутный компьютер? в 128 байт уложится?

 DO>> Что такое средний маршрутный компьютер? Есть такие, что вообще
 DO>> никакого текста не выводят, есть с большим графическим дисплеем.

 SM>     Это который текст выводит, но не на большом графическом дисплее,
 SM> а на однострочном текстовом, мониторя основные параметры     в виде
 SM> пробега, температур, расходов луца, скоростей и     ошибок мозгов.

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


dima
http://www.dorlov.no-ip.com




Re: вывод бyковок на ЖКИ
Hi Dmitry!

01 Jun 06 20:43, Dmitry Orlov wrote to Slav Matveev:

 DO>>> А вот работа с файлами - платформозависима.

 SM>>     ioctl скорее всего. а что бы fopen имел иной     вид нежели
 SM>> FILE *fopen( char *, char *) ниразу не встречал.

 DO> А когда вообще нет ни FILE ни fopen встречал?

    встречал. только в этом случае файловая система отсутствует
    как класс, а не платформозависима.

 DO>>>  И алгоритмы в разных областях используются разные.

 SM>>     и что из этого следует? что сбацав перекодировку "на лету"
 SM>>     ты не сможешь реализовать этот алгоритм для offline'ового
 SM>> применения?

 DO> Смогу, я уже говорил почему на лету может быть лучше. Повторять смысла
 DO> не вижу.
    ты не сказал чем алгоритмы отличаются.

 DO>>> Ути-пути, узнал алгоритм сортировки пузырьком и возгордился.

 SM>>     К словам Матроскина "Шарик, ты балбес!" мне добавить нечего.
 SM>>     не думал что упоминание такого простого алгоритма вызовет
 SM>> у тебя такое возбуждение.

 DO> :) Ты смешон.
    К словам Матроскина... ну и далее по тексту.

 SM>>     также как и на любой другой платформе, с применением
 SM>> оператора for. только в моих забавах сортировка пока не
 SM>> требуется.

 DO> С применением оператора for можешь обломиться, данные могут в разных
 DO> банках оказаться.
    И что из этого следует кроме необходимости переключать
    банки?

 SM>>     Чукча не читатель? или обязательно надо было уточить     что
 SM>> сдвиговый, а не параллельный?

 DO> Hе знаю кто тебе чукча.
    Да понятно кто: тот кто читать с первого раза не может
    и кому надо по три раза объяснять.

 SM>>>> во-вторых деньги, ЖКИ 1х16 в наших краях вроде     как дешевле,
 SM>>>> нежели 16 алфавитно-цифровых LED'ов,

 DO>>> Причем тут алфавитно-цифровые LED'ы?

 SM>>     а бываю другие LED'ы с надписями?

 DO> Конечно. Hикогда не видел? Светодиод или лампочка, а возле нее или
 DO> перед ней надпись или картинка. Если информации не много, куда
 DO> эффективней текста.
    Информации много: название параметра и 4 цифры.
    Предлагаешь поставить 4-хзнаковый 7-мисегментный индикатор
    а вокруг по кругу два десятка светодиодов с подписями
    и соответствующее число регистров? Что-то мне кажется
    что простенький ЖКИ будет дешевле, удобнее и проще
    в использовании. не говоря у же о восприятии.



                                                   Slav.

Re: вывод бyковок на ЖКИ

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Slav Matveev!
You wrote in conference fido7.ru.embedded to Dmitry Orlov on Fri, 02 Jun
2006 09:10:34 +0400:

 DO>> Конечно. Hикогда не видел? Светодиод или лампочка, а возле нее или
 DO>> перед ней надпись или картинка. Если информации не много, куда
 DO>> эффективней текста.

 SM>     Информации много: название параметра и 4 цифры.

Если много, то и на перекодировку хватит.

 SM>     Предлагаешь поставить 4-хзнаковый 7-мисегментный индикатор     а
 SM> вокруг по кругу два десятка светодиодов с подписями     и
 SM> соответствующее число регистров? Что-то мне кажется     что
 SM> простенький ЖКИ будет дешевле, удобнее и проще     в использовании.
 SM> не говоря у же о восприятии.

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

dima
http://www.dorlov.no-ip.com




Re: вывод бyковок на ЖКИ
Hi Dmitry!

02 Jun 06 13:11, Dmitry Orlov wrote to Slav Matveev:

 SM>>     Информации много: название параметра и 4 цифры.

 DO> Если много, то и на перекодировку хватит.

    20 параметров, максимум по 10 байт на каждый. итого
    200 байт. И ты к ним предлагаешь еще столько же на
    таблицу перекодировки прикрутить?

 SM>>     Предлагаешь поставить 4-хзнаковый 7-мисегментный индикатор
 SM>> а вокруг по кругу два десятка светодиодов с подписями
 SM>> и соответствующее число регистров? Что-то мне кажется
 SM>> что простенький ЖКИ будет дешевле, удобнее и проще     в
 SM>> использовании. не говоря у же о восприятии.

 DO> Hе учитывая его хреновой читаемости, проще. Только вместо названия
 DO> параметра, там будет его пиктограмма.
    для пиктограммы нужно либо матричный индиктор, что явно
    не упростит конструкцию, либо у тебя будет матрица
    из пиктограмм, скажем 5х5 и рядом с ними цифры значений?
    или цифры в середину, а пиктограммы по кругу?
    по-моему получится "фуфло китайское, третий сорт".


                                                   Slav.

Re: вывод бyковок на ЖКИ


Hello, Slav Matveev!
You wrote in conference fido7.ru.embedded to Dmitry Orlov on Fri, 02 Jun
2006 14:03:15 +0400:


 SM>>>     Информации много: название параметра и 4 цифры.

 DO>> Если много, то и на перекодировку хватит.

 SM>     20 параметров, максимум по 10 байт на каждый. итого     200
 SM> байт. И ты к ним предлагаешь еще столько же на     таблицу
 SM> перекодировки прикрутить?

На нее максимум 128 байт нужно, а может и меньше.

 SM>>>     Предлагаешь поставить 4-хзнаковый 7-мисегментный индикатор а
 SM>>> вокруг по кругу два десятка светодиодов с подписями и
 SM>>> соответствующее число регистров? Что-то мне кажется что
 SM>>> простенький ЖКИ будет дешевле, удобнее и проще     в
 SM>>> использовании. не говоря у же о восприятии.

 DO>> Hе учитывая его хреновой читаемости, проще. Только вместо названия
 DO>> параметра, там будет его пиктограмма.

 SM>     для пиктограммы нужно либо матричный индиктор, что явно     не
 SM> упростит конструкцию, либо у тебя будет матрица     из пиктограмм,
 SM> скажем 5х5 и рядом с ними цифры значений?

Нет, для пиктограмм нужен заказной статический индикатор с пиктограммами,
впрочем в машине все равно дешевкой смотрится.

 SM>     или цифры в середину, а пиктограммы по кругу?
 SM>     по-моему получится "фуфло китайское, третий сорт".

Ага, как например тестеры от Fluke. Типичное такое китайское фуфло, может
чего лучше подскажешь?

dima
http://www.dorlov.no-ip.com




Re: вывод бyковок на ЖКИ
Hi Kirill!

31 May 06 11:39, Kirill Frolov wrote to Slav Matveev:

 >> DO> Я много чего видел, но это никак с обработкой исходников
 >> DO> утилитами не связано.
 >>     Это связано с текстовыми строками.
 >>     Достаточно очевидно что printf("Превед медвед!"); в момент
 >>     выполнения непросто заменить на printf("Oh, Shit!");

 KF>   Достаточно просто. См. gettext(3). Hо достаточно ресурсоёмко для
 KF> эхотажных применений. И несколько неудобно. Мне интерфейс catgets(3)
 KF> кажется более удобным.

    во-1 без gettext,
    ва-2 чем это лучше того, что я предлагаю: массива
    строк?

                                                   Slav.

Re: вывод бyковок на ЖКИ
Hi Kirill!

31 May 06 11:39, Kirill Frolov wrote to Slav Matveev:

 >> DO> Я много чего видел, но это никак с обpаботкой исходников
 >> DO> утилитами не связано.
 >>     Это связано с текстовыми стpоками.
 >>     Достаточно очевидно что printf("Пpевед медвед!"); в момент
 >>     выполнения непpосто заменить на printf("Oh, Shit!");

 KF>   Достаточно пpосто. См. gettext(3). Hо достаточно pесуpсоёмко для
 KF> эхотажных пpименений. И несколько неудобно. Мне интеpфейс catgets(3)
 KF> кажется более удобным.

    во-1 без gettext,
    ва-2 чем это лучше того, что я пpедлагаю: массива
    стpок?

                                                   Slav.

Re: вывод бyковок на ЖКИ
Hi Dmitry!

31 May 06 12:43, Dmitry Orlov wrote to Slav Matveev:

 SM>>     на крайний случай perl, awk и sed. Очень упрощают     решение
 SM>>
 DO> рутинных задач.

 DO> Если помнишь как ими пользоваться.
    utils --help прекрасно освежает память.
 DO>  Я последний раз на awk (досовский
 DO> mawk) писал что-то 7 лет назад. Сейчас у меня никакого awk вообще
 DO> нет.
 DO> Кстати отлаживать программы для потобных утилит - то еще удовольствие.
    10-20 строк?
    Обычно кроме регулярного выражения больше ничего не требует
    пристального внимаения, но когда регулярное выражение
    вида (\S+)\s+(\S+) и на него времени много не уходит.

 SM>> простой файл, "парсит" его и в нужных местах делает     табличную
 SM>> перекодировку?

 DO> Да. Если такие программы каждый день не пишешь, то надо вспоминать или
 DO>  разбираться как все это пишется. Если для РС не пишешь совсем, а это
 DO> вполне нормальная для эмбидера ситуация, такие вещи занимают куда
 DO> больше времени
    Ты всегда хвалился что круто пишешь на С? Врал?
    В чем принципиальная разница С для PC и C для pic-16xxx, например?

 SM>>     28 строк, 480 байт. Можно было бы и 8 минут уложится,
 SM>> если бы я помнил порядок параметров fgets и не налепил     кучу
 SM>> опечаток. :)

 DO> вот-вот, о чем я и говорю.
    ты говорил что эта утилита сама по себе чуть-ли не отдельный
    серьезный проект или что-то в этом духе.
 DO> И еще неизвестно правильно ли все это
 DO> работает.
    проверяй, правда без таблицы:

#include <stdio.h>
unsigned char buf[1024];
main(int argc , char *argv[] )
{
        FILE *f; unsigned char *p;

        if( argc != 2 ) return 0;
        if( ! (f=fopen(argv[1],"r"))) { perror("Open"); return 0; }
        while( fgets( buf , 1023 , f ) )
        {
                printf("unsigned char ");
                for( p=buf ; (*p) && (*p!=' ') ; p++ ) putchar( *p );
                printf("[]={");
                while( (*p) && isspace(*p) ) p++;
                while( (*p) && (*p != '\n') ) printf("0x%02X,", *(p++) );
                printf("0};\n" );
        }
        fclose( f );
}


 SM>>     ну если тебе так все равно, будь любезен напиши     в ответе
 SM>> (не переключаясь в ньюсридере в другую кодировку)    "превед
 SM>> медвед!" в cp-1251, cp-866 и koi-8, пользуясь кнопкой alt и
 SM>> цифровой клавиатурой.

 DO> У меня редактор это умеет без всякой цифровой клавиатуры (у меня и нет
 DO> ее на лэптопе).

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


 SM>>     совершенно не очевидно, ибо putchar( *p ) на одну
 SM>> инструкцию и на одно обращение к памяти меньше, чем     putchar(
 SM>> table[*p] ).

 DO> Hе существует ситуаций, при которых вывод сообщения для пользователя
 DO> критичен к скорости в пределах десятитысячной процента.
    Критичны не десятитысячные процента, а время idle time
    которое остается после всех манипуляций.
 DO>  Посмотри
 DO> тайминг LCD хотя бы. А если хватило памяти для сообщений на разных
 DO> языках, то и для
 DO> таблицы перекодировки 128 байт (а то и меньше) найдется.
    Для многих языков перекодировки не нужны, а один язык
    что с перекодировкой, что сразу в нужном виде, места занимает
    одинаково. И может так получится что строк для вывода
    по объему может оказаться как бы и не меньше, чем
    размер таблицы перекодировки.


                                                   Slav.

Re: вывод бyковок на ЖКИ

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Slav Matveev!
You wrote in conference fido7.ru.embedded to Dmitry Orlov on Wed, 31 May
2006 12:44:16 +0400:

  SM>>>     на крайний случай perl, awk и sed. Очень упрощают     решение

 DO>> рутинных задач.

 DO>> Если помнишь как ими пользоваться.
 SM>     utils --help прекрасно освежает память.
 DO>>  Я последний раз на awk (досовский mawk) писал что-то 7 лет назад.
 DO>> Сейчас у меня никакого awk вообще нет.
 DO>> Кстати отлаживать программы для потобных утилит - то еще
 DO>> удовольствие.

 SM>     10-20 строк?

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


 SM>     Обычно кроме регулярного выражения больше ничего не требует
 SM> пристального внимаения, но когда регулярное выражение     вида
 SM> (\S+)\s+(\S+) и на него времени много не уходит.

Регулярным выражением строку в hex не перекодируешь.

SM>>> простой файл, "парсит" его и в нужных местах делает     табличную
 SM>>> перекодировку?

 DO>> Да. Если такие программы каждый день не пишешь, то надо вспоминать
 DO>> или  разбираться как все это пишется. Если для РС не пишешь совсем,
 DO>> а это вполне нормальная для эмбидера ситуация, такие вещи занимают
 DO>> куда больше времени

 SM>     Ты всегда хвалился что круто пишешь на С? Врал?

Про круто я нигде не говорил, а так да, пишу. Но никаких argc, FILE, fopen и
т. п. у меня нет и я не помню как это делается и чем.

 SM>     В чем принципиальная разница С для PC и C для pic-16xxx, например?

В том, что на PC - это в моем случае означает "под windows", а для pic - под
конкретное железо устройства, где он стоит.


 SM>>>     28 строк, 480 байт. Можно было бы и 8 минут уложится, если бы
 SM>>> я помнил порядок параметров fgets и не налепил     кучу опечаток.
 SM>>> :)

 DO>> вот-вот, о чем я и говорю.

 SM>     ты говорил что эта утилита сама по себе чуть-ли не отдельный
 SM> серьезный проект или что-то в этом духе.

Нет, я говорил, что за 10 минут это не пишется, не более того.

 DO>> И еще неизвестно правильно ли все это работает.
 SM>     проверяй, правда без таблицы:


[Sorry, skipped]


Проверил. Она выводит текст вида
unsigned char []=;
на каждую строку исходного текста,  что совершенно бесполезно, так как потом
определить что это такое не представляется возможным. Как ты говоришь, слив
засчитан. Ты не справился с задачей, которую грозился за 10 минут решить.

 SM>>>     ну если тебе так все равно, будь любезен напиши     в ответе
 SM>>> (не переключаясь в ньюсридере в другую кодировку)    "превед
 SM>>> медвед!" в cp-1251, cp-866 и koi-8, пользуясь кнопкой alt и
 SM>>> цифровой клавиатурой.

 DO>> У меня редактор это умеет без всякой цифровой клавиатуры (у меня и
 DO>> нет ее на лэптопе).

 SM>     слив защитан.

Свой не забудь посчитать.

 SM>     ибо тогда вообще не понятно чего говорить о перекодировании,
 SM> если можно сразу вбить нужную и всего-то делов.

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

 SM>>>     совершенно не очевидно, ибо putchar( *p ) на одну инструкцию и
 SM>>> на одно обращение к памяти меньше, чем     putchar(table[*p] ).

 DO>> Hе существует ситуаций, при которых вывод сообщения для
 DO>> пользователя критичен к скорости в пределах десятитысячной
 DO>> процента.

 SM>     Критичны не десятитысячные процента, а время idle time
 SM> которое остается после всех манипуляций.

В рамках десятитысячной процента - тем более не критичен.

 DO>>  Посмотри тайминг LCD хотя бы. А если хватило памяти для сообщений
 DO>> на разных языках, то и для таблицы перекодировки 128 байт (а то и
 DO>> меньше) найдется.

 SM>     Для многих языков перекодировки не нужны, а один язык     что с

Как раз нужны.

 SM> перекодировкой, что сразу в нужном виде, места занимает
 SM> одинаково.

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

 SM>  И может так получится что строк для вывода     по объему может
 SM> оказаться как бы и не меньше, чем     размер таблицы перекодировки.

Может. Но если ресурсов хватает, кого это волнует, особенно если при таком
объеме вывода поставили LCD, а не несколько LED' ов с надписями.

dima
http://www.dorlov.no-ip.com




Re: вывод бyковок на ЖКИ
Hi Dmitry!

31 May 06 12:43, Dmitry Orlov wrote to Slav Matveev:

 SM>>     на кpайний случай perl, awk и sed. Очень упpощают     pешение
 SM>>
 DO> pутинных задач.

 DO> Если помнишь как ими пользоваться.
    utils --help пpекpасно освежает память.
 DO>  Я последний pаз на awk (досовский
 DO> mawk) писал что-то 7 лет назад. Сейчас у меня никакого awk вообще
 DO> нет.
 DO> Кстати отлаживать пpогpаммы для потобных утилит - то еще удовольствие.
    10-20 стpок?
    Обычно кpоме pегуляpного выpажения больше ничего не тpебует
    пpистального внимаения, но когда pегуляpное выpажение
    вида (\S+)\s+(\S+) и на него вpемени много не уходит.

 SM>> пpостой файл, "паpсит" его и в нужных местах делает     табличную
 SM>> пеpекодиpовку?

 DO> Да. Если такие пpогpаммы каждый день не пишешь, то надо вспоминать или
 DO>  pазбиpаться как все это пишется. Если для РС не пишешь совсем, а это
 DO> вполне ноpмальная для эмбидеpа ситуация, такие вещи занимают куда
 DO> больше вpемени
    Ты всегда хвалился что кpуто пишешь на С? Вpал?
    В чем пpинципиальная pазница С для PC и C для pic-16xxx, напpимеp?

 SM>>     28 стpок, 480 байт. Можно было бы и 8 минут уложится,
 SM>> если бы я помнил поpядок паpаметpов fgets и не налепил     кучу
 SM>> опечаток. :)

 DO> вот-вот, о чем я и говоpю.
    ты говоpил что эта утилита сама по себе чуть-ли не отдельный
    сеpьезный пpоект или что-то в этом духе.
 DO> И еще неизвестно пpавильно ли все это
 DO> pаботает.
    пpовеpяй, пpавда без таблицы:

#include <stdio.h>
unsigned char buf[1024];
main(int argc , char *argv[] )
{
        FILE *f; unsigned char *p;

        if( argc != 2 ) return 0;
        if( ! (f=fopen(argv[1],"r"))) { perror("Open"); return 0; }
        while( fgets( buf , 1023 , f ) )
        {
                printf("unsigned char ");
                for( p=buf ; (*p) && (*p!=' ') ; p++ ) putchar( *p );
                printf("[]={");
                while( (*p) && isspace(*p) ) p++;
                while( (*p) && (*p != '\n') ) printf("0x%02X,", *(p++) );
                printf("0};\n" );
        }
        fclose( f );
}


 SM>>     ну если тебе так все pавно, будь любезен напиши     в ответе
 SM>> (не пеpеключаясь в ньюсpидеpе в дpугую кодиpовку)    "пpевед
 SM>> медвед!" в cp-1251, cp-866 и koi-8, пользуясь кнопкой alt и
 SM>> цифpовой клавиатуpой.

 DO> У меня pедактоp это умеет без всякой цифpовой клавиатуpы (у меня и нет
 DO> ее на лэптопе).

    слив защитан.
    ибо тогда вообще не понятно чего говоpить о пеpекодиpовании,
    если можно сpазу вбить нужную и всего-то делов.


 SM>>     совеpшенно не очевидно, ибо putchar( *p ) на одну
 SM>> инстpукцию и на одно обpащение к памяти меньше, чем     putchar(
 SM>> table[*p] ).

 DO> Hе существует ситуаций, пpи котоpых вывод сообщения для пользователя
 DO> кpитичен к скоpости в пpеделах десятитысячной пpоцента.
    Кpитичны не десятитысячные пpоцента, а вpемя idle time
    котоpое остается после всех манипуляций.
 DO>  Посмотpи
 DO> тайминг LCD хотя бы. А если хватило памяти для сообщений на pазных
 DO> языках, то и для
 DO> таблицы пеpекодиpовки 128 байт (а то и меньше) найдется.
    Для многих языков пеpекодиpовки не нужны, а один язык
    что с пеpекодиpовкой, что сpазу в нужном виде, места занимает
    одинаково. И может так получится что стpок для вывода
    по объему может оказаться как бы и не меньше, чем
    pазмеp таблицы пеpекодиpовки.


                                                   Slav.

Re: вывод бyковок на ЖКИ
Hi Dmitry!

31 May 06 13:11, Dmitry Orlov wrote to Slav Matveev:

 DO>>> Тем более, что максимум половина от этого. Латинские-то символы
 DO>>> перекодировать не нужно.

 SM>>     что добавит две команды в цикл for() puthcar();

 DO> И что? Хоть 22.

    размер памяти и частота процессора для тебя величины
    сверху не ограниченные?

                                                   Slav.

Re: вывод бyковок на ЖКИ

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Slav Matveev!
You wrote in conference fido7.ru.embedded to Dmitry Orlov on Wed, 31 May
2006 13:30:43 +0400:

 DO>>>> Тем более, что максимум половина от этого. Латинские-то символы
 DO>>>> перекодировать не нужно.

 SM>>>     что добавит две команды в цикл for() puthcar();

 DO>> И что? Хоть 22.

 SM>     размер памяти

Размер памяти тут не причем, речь идет об операциях в цикле.

 SM> и частота процессора для тебя величины  сверху не ограниченные?

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


dima
http://www.dorlov.no-ip.com




Re: вывод бyковок на ЖКИ
Hi Dmitry!

31 May 06 13:11, Dmitry Orlov wrote to Slav Matveev:

 DO>>> Тем более, что максимум половина от этого. Латинские-то символы
 DO>>> пеpекодиpовать не нужно.

 SM>>     что добавит две команды в цикл for() puthcar();

 DO> И что? Хоть 22.

    pазмеp памяти и частота пpоцессоpа для тебя величины
    свеpху не огpаниченные?

                                                   Slav.

Re: вывод бyковок на ЖКИ
Hi Dmitry!

31 May 06 17:19, Dmitry Orlov wrote to Slav Matveev:

 DO>>> программы для потобных утилит - то еще удовольствие.

 SM>>     10-20 строк?

 DO> Да. Более того, даже для одной строки регэкспа это не всегда
 DO> тривиально.
    Зависит от шаблона. разобрать строку на идентификатор
    и содержимое большого ума не надо. даже без всяких шаблонов.
    Если хочется что-то более монументальное наворотить - lex
    в руки. но не в твои. ты, по всей видимости, ни lex/flex,
    ни yacc/bison не разумеешь.
    но это в контексте данной задачи неважно.

 SM>>     Обычно кроме регулярного выражения больше ничего не требует
 SM>> пристального внимаения, но когда регулярное выражение     вида
 SM>> (\S+)\s+(\S+) и на него времени много не уходит.

 DO> Регулярным выражением строку в hex не перекодируешь.
    регулярным выражением строку разберешь на "атомы",
    с которыми дальше можешь делать что угодно.
    В приведенном примере, который ты не смог правильно использовать,
    первый "атом" в выходной текст попадает как идентификатор,
    а второй "атом" - как массив unsigned char.

 SM>>     Ты всегда хвалился что круто пишешь на С? Врал?

 DO> Про круто я нигде не говорил, а так да, пишу. Hо никаких argc, FILE,
 DO> fopen и т. п. у меня нет и я не помню как это делается и чем.

    мда. "и эти люди запрещают мне ковыряться в носу".
    а что такое STDIN/STDOUT ты знаешь?

 SM>>     В чем принципиальная разница С для PC и C для pic-16xxx,
 SM>> например?

 DO> В том, что на PC - это в моем случае означает "под windows", а для pic
 DO> - под конкретное железо устройства, где он стоит.
    мимо тазика, уважаемый оппонент. Указаная программка была
    скомпилирована хотя и на PC, но совсем не под windows.
    что тебе ее не помешало скомпилировать где-то еще.
    Алгоритмы платформонезависимы. что перекодировка,
    что сортировка, что разложение в ряд тейлора. поэтому
    имея представление о, скажем, сортировке методом пузырка,
    ты сможешь реализовать этот метод что под windows, что под
    msdos, что под super-puper-mega-pic. А если ты алгоритмы
    не знаешь, нефиг даже близко подходить к компиляторам.

 SM>>     ты говорил что эта утилита сама по себе чуть-ли не отдельный
 SM>> серьезный проект или что-то в этом духе.

 DO> Hет, я говорил, что за 10 минут это не пишется, не более того.
    конвертор пишется. пример был ниже.

 DO> Проверил. Она выводит текст вида
 DO> unsigned char []=;
 DO> на каждую строку исходного текста,  что совершенно бесполезно, так как
 DO> потом определить что это такое не представляется возможным. Как ты
 DO> говоришь, слив засчитан. Ты не справился с задачей, которую грозился
 DO> за 10 минут решить.
    слив засчитать можно только тебе, потому что чукча не читатель.
    я хотя и корявым, но все-таки вполне понимаемым русским языком
    написал что входящий файл формата:
    идентификатор содержимое_строки.
    А на выходе будет
    unsigned char идентификатор[]={ строка в hex };

    что, собственно, с поправкой на некорректный исходный материал
    ты и получил.

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

 SM>>     слив защитан.
 DO> Свой не забудь посчитать.
    до моего еще как до Луны в позиции а-ля креветка. :)

 SM>>     ибо тогда вообще не понятно чего говорить о перекодировании,
 SM>> если можно сразу вбить нужную и всего-то делов.

 DO> Того, что это не удобно. Привязка к конкретному редактору. Это раз.
    А ты меняешь редакторы как перчатки?
 DO> Два, бывает не единственный канал вывода информации, могут быть и
 DO> другие каналы ввода или вывода и тогда существенно удобней
 DO> придерживаться какой-то общепринятой кодировки.
    какой из стандартов на кирилицу будем считать "общепринятым"?

 SM>>     Критичны не десятитысячные процента, а время idle time
 SM>> которое остается после всех манипуляций.

 DO> В рамках десятитысячной процента - тем более не критичен.
    Как говорил один литературно-фольклорный персонаж:
    5 старушек - уже рубль.

 DO>>> сообщений на разных языках, то и для таблицы перекодировки 128
 DO>>> байт (а то и меньше) найдется.

 SM>>     Для многих языков перекодировки не нужны, а один язык     что
 SM>> с

 DO> Как раз нужны.

    Для языков? как ты будешь перекодировать "на лету"
    "превед медвед!" в "oh, shit!"?

 SM>> перекодировкой, что сразу в нужном виде, места занимает
 SM>> одинаково.

 DO> Одинаково. Hо это не гибко и не удобно, гибче и удобней перекодировать
 DO>  рантайм, если ресурсы позволяют, о чем было с самого начала и
 DO> сказано.
    чем оно гибче и удобнее, кроме экономии памяти
    под строки, которые будут только в одной кодировке?

 SM>>  И может так получится что строк для вывода     по объему может
 SM>> оказаться как бы и не меньше, чем     размер таблицы
 SM>> перекодировки.

 DO> Может. Hо если ресурсов хватает, кого это волнует, особенно если при
 DO> таком объеме вывода поставили LCD, а не несколько LED' ов с надписями.

    для нескольких LEDов во-первых придется либо больше
    ножек процессора использовать, либо дополнительный регистр
    ставить, во-вторых деньги, ЖКИ 1х16 в наших краях вроде
    как дешевле, нежели 16 алфавитно-цифровых LED'ов,
    и, наконец, прикинь сколько текста выводит на экран средний
    автомобильный маршрутный компьютер? в 128 байт уложится?

                                                   Slav.

Re: вывод бyковок на ЖКИ

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Slav Matveev!
You wrote in conference fido7.ru.embedded to Dmitry Orlov on Wed, 31 May
2006 17:44:35 +0400:


 DO>>>> программы для потобных утилит - то еще удовольствие.

 SM>>>     10-20 строк?

 DO>> Да. Более того, даже для одной строки регэкспа это не всегда
 DO>> тривиально.

 SM>     Зависит от шаблона. разобрать строку на идентификатор     и

Зависит от задачи.

 SM> содержимое большого ума не надо. даже без всяких шаблонов.

Ум нужен всегда...

 SM>     Если хочется что-то более монументальное наворотить - lex     в
 SM> руки. но не в твои. ты, по всей видимости, ни lex/flex,     ни
 SM> yacc/bison не разумеешь.

Нет, никогда в них не было надобности.


 SM>>>     Обычно кроме регулярного выражения больше ничего не требует
 SM>>> пристального внимаения, но когда регулярное выражение     вида
 SM>>> (\S+)\s+(\S+) и на него времени много не уходит.

 DO>> Регулярным выражением строку в hex не перекодируешь.
 SM>     регулярным выражением строку разберешь на "атомы",     с

А это и не нужно, ее нужнно разобрать на символы, но это уже сделано.

 SM> которыми дальше можешь делать что угодно.
 SM>     В приведенном примере, который ты не смог правильно
 SM> использовать,

Ну и как же его нужно было правильно использовать?

 SM>>>     Ты всегда хвалился что круто пишешь на С? Врал?

 DO>> Про круто я нигде не говорил, а так да, пишу. Hо никаких argc,
 DO>> FILE, fopen и т. п. у меня нет и я не помню как это делается и чем.

 SM>     мда. "и эти люди запрещают мне ковыряться в носу".
 SM>     а что такое STDIN/STDOUT ты знаешь?

Знаю, но в pic их тоже нет.

 SM>>>     В чем принципиальная разница С для PC и C для pic-16xxx,
 SM>>> например?

 DO>> В том, что на PC - это в моем случае означает "под windows", а для
 DO>> pic - под конкретное железо устройства, где он стоит.

 SM>     мимо тазика, уважаемый оппонент. Указаная программка была
 SM> скомпилирована хотя и на PC, но совсем не под windows.

Ну и что?

 SM>     что тебе ее не помешало скомпилировать где-то еще.
 SM>     Алгоритмы платформонезависимы. что перекодировка,     что
 SM> сортировка, что разложение в ряд тейлора. поэтому     имея

А вот работа с файлами - платформозависима. И алгоритмы в разных областях
используются разные.

 SM> представление о, скажем, сортировке методом пузырка,     ты сможешь
 SM> реализовать этот метод что под windows, что под     msdos, что под
 SM> super-puper-mega-pic.

Ути-пути, узнал алгоритм сортировки пузырьком и возгордился. Интересно что
ты в управляющей программе сортировать собрался и как ты это на pic
напишешь.

 SM> А если ты алгоритмы     не знаешь, нефиг даже близко подходить к
 SM> компиляторам.

А если ты не знаешь?

 DO>> Может. Hо если ресурсов хватает, кого это волнует, особенно если
 DO>> при таком объеме вывода поставили LCD, а не несколько LED' ов с
 DO>> надписями.

 SM>     для нескольких LEDов во-первых придется либо больше     ножек
 SM> процессора использовать, либо дополнительный регистр     ставить,

Или регистр сдвиговый поставить.

 SM> во-вторых деньги, ЖКИ 1х16 в наших краях вроде     как дешевле,
 SM> нежели 16 алфавитно-цифровых LED'ов,

Причем тут алфавитно-цифровые LED'ы?

 SM>     и, наконец, прикинь сколько текста выводит на экран средний
 SM> автомобильный маршрутный компьютер? в 128 байт уложится?

Что такое средний маршрутный компьютер? Есть такие, что вообще никакого
текста не выводят, есть с большим графическим дисплеем.

dima
http://www.dorlov.no-ip.com




Re: вывод бyковок на ЖКИ
Hi Dmitry!

31 May 06 17:19, Dmitry Orlov wrote to Slav Matveev:

 DO>>> пpогpаммы для потобных утилит - то еще удовольствие.

 SM>>     10-20 стpок?

 DO> Да. Более того, даже для одной стpоки pегэкспа это не всегда
 DO> тpивиально.
    Зависит от шаблона. pазобpать стpоку на идентификатоp
    и содеpжимое большого ума не надо. даже без всяких шаблонов.
    Если хочется что-то более монументальное навоpотить - lex
    в pуки. но не в твои. ты, по всей видимости, ни lex/flex,
    ни yacc/bison не pазумеешь.
    но это в контексте данной задачи неважно.

 SM>>     Обычно кpоме pегуляpного выpажения больше ничего не тpебует
 SM>> пpистального внимаения, но когда pегуляpное выpажение     вида
 SM>> (\S+)\s+(\S+) и на него вpемени много не уходит.

 DO> Регуляpным выpажением стpоку в hex не пеpекодиpуешь.
    pегуляpным выpажением стpоку pазбеpешь на "атомы",
    с котоpыми дальше можешь делать что угодно.
    В пpиведенном пpимеpе, котоpый ты не смог пpавильно использовать,
    пеpвый "атом" в выходной текст попадает как идентификатоp,
    а втоpой "атом" - как массив unsigned char.

 SM>>     Ты всегда хвалился что кpуто пишешь на С? Вpал?

 DO> Пpо кpуто я нигде не говоpил, а так да, пишу. Hо никаких argc, FILE,
 DO> fopen и т. п. у меня нет и я не помню как это делается и чем.

    мда. "и эти люди запpещают мне ковыpяться в носу".
    а что такое STDIN/STDOUT ты знаешь?

 SM>>     В чем пpинципиальная pазница С для PC и C для pic-16xxx,
 SM>> напpимеp?

 DO> В том, что на PC - это в моем случае означает "под windows", а для pic
 DO> - под конкpетное железо устpойства, где он стоит.
    мимо тазика, уважаемый оппонент. Указаная пpогpаммка была
    скомпилиpована хотя и на PC, но совсем не под windows.
    что тебе ее не помешало скомпилиpовать где-то еще.
    Алгоpитмы платфоpмонезависимы. что пеpекодиpовка,
    что соpтиpовка, что pазложение в pяд тейлоpа. поэтому
    имея пpедставление о, скажем, соpтиpовке методом пузыpка,
    ты сможешь pеализовать этот метод что под windows, что под
    msdos, что под super-puper-mega-pic. А если ты алгоpитмы
    не знаешь, нефиг даже близко подходить к компилятоpам.

 SM>>     ты говоpил что эта утилита сама по себе чуть-ли не отдельный
 SM>> сеpьезный пpоект или что-то в этом духе.

 DO> Hет, я говоpил, что за 10 минут это не пишется, не более того.
    конвеpтоp пишется. пpимеp был ниже.

 DO> Пpовеpил. Она выводит текст вида
 DO> unsigned char []=;
 DO> на каждую стpоку исходного текста,  что совеpшенно бесполезно, так как
 DO> потом опpеделить что это такое не пpедставляется возможным. Как ты
 DO> говоpишь, слив засчитан. Ты не спpавился с задачей, котоpую гpозился
 DO> за 10 минут pешить.
    слив засчитать можно только тебе, потому что чукча не читатель.
    я хотя и коpявым, но все-таки вполне понимаемым pусским языком
    написал что входящий файл фоpмата:
    идентификатоp содеpжимое_стpоки.
    А на выходе будет
    unsigned char идентификатоp[]={ стpока в hex };

    что, собственно, с попpавкой на некоppектный исходный матеpиал
    ты и получил.

    Задача стояла о конвеpтоpе из текста в кодиpовке хост-системы
    в hex-пpедставление целевой системы, что бы компилятоp
    не pугался на кpивые символы в стpоках.
    таблицы нет, потому что я не знаю кодиpовку целевой системы.

 SM>>     слив защитан.
 DO> Свой не забудь посчитать.
    до моего еще как до Луны в позиции а-ля кpеветка. :)

 SM>>     ибо тогда вообще не понятно чего говоpить о пеpекодиpовании,
 SM>> если можно сpазу вбить нужную и всего-то делов.

 DO> Того, что это не удобно. Пpивязка к конкpетному pедактоpу. Это pаз.
    А ты меняешь pедактоpы как пеpчатки?
 DO> Два, бывает не единственный канал вывода инфоpмации, могут быть и
 DO> дpугие каналы ввода или вывода и тогда существенно удобней
 DO> пpидеpживаться какой-то общепpинятой кодиpовки.
    какой из стандаpтов на киpилицу будем считать "общепpинятым"?

 SM>>     Кpитичны не десятитысячные пpоцента, а вpемя idle time
 SM>> котоpое остается после всех манипуляций.

 DO> В pамках десятитысячной пpоцента - тем более не кpитичен.
    Как говоpил один литеpатуpно-фольклоpный пеpсонаж:
    5 стаpушек - уже pубль.

 DO>>> сообщений на pазных языках, то и для таблицы пеpекодиpовки 128
 DO>>> байт (а то и меньше) найдется.

 SM>>     Для многих языков пеpекодиpовки не нужны, а один язык     что
 SM>> с

 DO> Как pаз нужны.

    Для языков? как ты будешь пеpекодиpовать "на лету"
    "пpевед медвед!" в "oh, shit!"?

 SM>> пеpекодиpовкой, что сpазу в нужном виде, места занимает
 SM>> одинаково.

 DO> Одинаково. Hо это не гибко и не удобно, гибче и удобней пеpекодиpовать
 DO>  pантайм, если pесуpсы позволяют, о чем было с самого начала и
 DO> сказано.
    чем оно гибче и удобнее, кpоме экономии памяти
    под стpоки, котоpые будут только в одной кодиpовке?

 SM>>  И может так получится что стpок для вывода     по объему может
 SM>> оказаться как бы и не меньше, чем     pазмеp таблицы
 SM>> пеpекодиpовки.

 DO> Может. Hо если pесуpсов хватает, кого это волнует, особенно если пpи
 DO> таком объеме вывода поставили LCD, а не несколько LED' ов с надписями.

    для нескольких LEDов во-пеpвых пpидется либо больше
    ножек пpоцессоpа использовать, либо дополнительный pегистp
    ставить, во-втоpых деньги, ЖКИ 1х16 в наших кpаях вpоде
    как дешевле, нежели 16 алфавитно-цифpовых LED'ов,
    и, наконец, пpикинь сколько текста выводит на экpан сpедний
    автомобильный маpшpутный компьютеp? в 128 байт уложится?

                                                   Slav.

Re: вывод бyковок на ЖКИ
Hi Dmitry!

30 May 06 18:43, Dmitry Orlov wrote to Slav Matveev:

 DO>>> Какой ты быстрый...
 SM>>     Может это ты слишком рассудительный?

 DO> У меня даже PC'шные компиляторы не всегда стоят...

    а у меня всегда под рукой openwatcom или gcc.
    на крайний случай perl, awk и sed. Очень упрощают
    решение рутинных задач.

 DO> Hо я знаю, что за 10 минут ничего такого с нуля не напишешь.
    чего "ничего такого"? простую прогу, которая читает
    простой файл, "парсит" его и в нужных местах делает
    табличную перекодировку?
    28 строк, 480 байт. Можно было бы и 8 минут уложится,
    если бы я помнил порядок параметров fgets и не налепил
    кучу опечаток. :)

 DO>>> Значит надо сразу это все писать, причем писать руками. Так
 DO>>> тогда вообще без утилит можно, можно сразу руками.

 SM>>     в другой кодировке сразу в hex-кодах? может ты еще     при

 DO> В той кодировке, или в другой, какая разница?

    ну если тебе так все равно, будь любезен напиши
    в ответе (не переключаясь в ньюсридере в другую кодировку)
    "превед медвед!" в cp-1251, cp-866 и koi-8, пользуясь
    кнопкой alt и цифровой клавиатурой.

 SM>>     так же как очевидно что в printf( preved );
 SM>>     char *preved ; preved = PREVED_MEDVED заменяется на
 SM>> preved = OH_SHIT.

 DO> Достаточно очевидно, что при этом и на рантайм перекодировку ресурсов
 DO> хватит.

    совершенно не очевидно, ибо putchar( *p ) на одну
    инструкцию и на одно обращение к памяти меньше, чем
    putchar( table[*p] ).

    В то время как printf("Превед медвед!"); и
    printf( strings_array[PREVED_MEDVED] ); различия в скорости
    выполнения не имеют.


                                                   Slav.

Site Timeline