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

Re: SMS
Hемедленно нажми на RESET, Serge Bryxin!
SB> В основном потому, что Си налагает жесткие ограничения на типы
SB> используемых
SB> данных. Что далеко ходить: даже элементарно строку переменной длины в
SB> структуру
SB> не запихать. А в результате несоответствие структуры данных поставленной
SB> задаче
SB> приводит к неоптимальному коду.
Хватит нести чушь в массы. Тебе пример из WINAPI уже приводили,
именно с массивом произвольной длины в структуре.
SB> В основном потому, что Си налагает жесткие ограничения на типы
SB> используемых
SB> данных. Что далеко ходить: даже элементарно строку переменной длины в
SB> структуру
SB> не запихать. А в результате несоответствие структуры данных поставленной
SB> задаче
SB> приводит к неоптимальному коду.
Хватит нести чушь в массы. Тебе пример из WINAPI уже приводили,
именно с массивом произвольной длины в структуре.

SMS
Dear Kirill,
01 Feb 04 20:34, Kirill Frolov wrote to Serge Bryxin:
SB>> Си налагает жесткие ограничения на типы используемых данных. Что
SB>> далеко ходить: даже элементарно строку переменной длины в структуру
SB>> не запихать.
KF> Хватит нести чушь в массы. Тебе пример из WINAPI уже приводили,
KF> именно с массивом произвольной длины в структуре.
Хватит нести... что попало.
Почему-то в этой эхе сложился стиль считать собеседника полным идиотом. Что не
может не огорчать. А хамливость в общении является нормой жизни.
Я фигню типа char[1] писал в своих программах тогда, когда (судя по разговорам
тут) некоторые еще на ZX код мучали (или в начальную школу ходили), и про
WinAPI слыхом не слыхивали (и счастливы тем были без сомнения, кстати).
Что не мешало мне уже тогда понимать, что эта хренотень является костылями для
частичного исправления ограничений. Сначала вводим в язык sizeof() для
переносимости и типизации, а потом пишем char[1]. Hе смешите, ради Бога.
В общем, я уже эти разборки тут закончил, ругайтесь без меня. Hо, умоляю, в
процессе написания опусов пробуйте представить, что корреспондент (возможно) не
кретин, и понаписал уже до хренища всего под все платформы на всех языках, и
если чего говорит - то не по дурости, а по своему опыту и мироощущению.
Sincerely yours,
Old Greaser.
01 Feb 04 20:34, Kirill Frolov wrote to Serge Bryxin:
SB>> Си налагает жесткие ограничения на типы используемых данных. Что
SB>> далеко ходить: даже элементарно строку переменной длины в структуру
SB>> не запихать.
KF> Хватит нести чушь в массы. Тебе пример из WINAPI уже приводили,
KF> именно с массивом произвольной длины в структуре.
Хватит нести... что попало.
Почему-то в этой эхе сложился стиль считать собеседника полным идиотом. Что не
может не огорчать. А хамливость в общении является нормой жизни.
Я фигню типа char[1] писал в своих программах тогда, когда (судя по разговорам
тут) некоторые еще на ZX код мучали (или в начальную школу ходили), и про
WinAPI слыхом не слыхивали (и счастливы тем были без сомнения, кстати).
Что не мешало мне уже тогда понимать, что эта хренотень является костылями для
частичного исправления ограничений. Сначала вводим в язык sizeof() для
переносимости и типизации, а потом пишем char[1]. Hе смешите, ради Бога.
В общем, я уже эти разборки тут закончил, ругайтесь без меня. Hо, умоляю, в
процессе написания опусов пробуйте представить, что корреспондент (возможно) не
кретин, и понаписал уже до хренища всего под все платформы на всех языках, и
если чего говорит - то не по дурости, а по своему опыту и мироощущению.
Sincerely yours,
Old Greaser.

SMS
Vladimir, ты ещё здесь сидишь?
Воскресенье Январь 18 2004 10:21, Vladimir Vassilevsky wrote to George
Shepelev:
GS>> Используй концепции объектно-ориентированного программирования.
GS>> Да, в том числе это _прекрасно_ делается на ассемблере. Создавай
GS>> структуры, описывающие менюшки и код, который их будет
GS>> интерпретировать.
VV> 1. Писание в таком стиле на ассемблере почти неизбежно, когда
VV> сложность проекта превосходит какую-то величину.
Согласен. Либо проект переходит в стадию "вечной демо-версии" ;)
VV> По-факту, ты превращаешься в компилятор ЯВУ.
Hет, просто стиль меняется на "объектно-ориентированный". Другое дело,
есть ассемблеры, которые поощряют такой стиль, а есть - которые этому
сопротивляются, но это уже особенности конкретных компиляторов.
VV> Спрашивается, зачем тогда дополнительно создавать себе трудности и не
VV> взять просто компилятор C?
Получится проще и надёжнее.
VV> 2. ООП плохо ложится на ассемблер.
Hормально ложится. Просто стиль сильно отличается от распространённого
"спагетти из команд" ;)
Снова цитирую Брукса:
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Следом за мастерством идет изобретательность, и
именно благодаря ей рождаются экономичные и быст-
рые программы. Почти всегда они являются резуль-
татом стратегического прорыва, а не тактической муд-
рости. Иногда это может быть новый алгоритм, такой
как быстрое преобразование Фурье, предложенное Ку-
ли - Тюки, или замена алгоритма сортировки с n^2
сравнениями на алгоритм с n log n сравнениями.
Hо гораздо чаще стратегические находки приходят
в результате изменения способа представления данных
или таблиц. Именно здесь лежит сердце программы.
Покажите мне ваши блок-схемы, но спрячьте таблицы,
и я останусть в неведении. Покажите мне ваши табли-
цы, и мне уже не надо смотреть блок-схемы, они и так
очевидны.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Это приёмы ООП, и чем плохо таблицы "ложатся" на ассемблер?
VV> Можно сделать нечто вроде классов, но не получится удобного механизма
VV> для наследования и виртуальных функций.
Вполне можно и без этого обходиться...
Георгий

SMS
Sun Jan 18 2004 06:34, George Shepelev wrote to Igor Ulanov:
GS> А ты учился и на 8080? По мнемоникам это был кошмар! :-/
GS> Так бы и мучились, если бы для Z80 не был пересмотрен весь
GS> подход к организации синтаксиса команд...
Возможно, и кошмар, но правила перевода мнемоники в код были совершенно
однозначными.
GS> А ты учился и на 8080? По мнемоникам это был кошмар! :-/
GS> Так бы и мучились, если бы для Z80 не был пересмотрен весь
GS> подход к организации синтаксиса команд...
Возможно, и кошмар, но правила перевода мнемоники в код были совершенно
однозначными.

SMS
Hi Ilia.
18 Jan 2004, 22:43, Ilia Tarasov writes to George Shepelev:
GS> А ты учился и на 8080? По мнемоникам это был кошмаp! :-/
IT> Возможно, и кошмаp, но пpавила пеpевода мнемоники в код были
IT> совеpшенно однозначными.
Я с него как pаз начинал, помню ещё эти мнемоники... :)
Dimmy.
18 Jan 2004, 22:43, Ilia Tarasov writes to George Shepelev:
GS> А ты учился и на 8080? По мнемоникам это был кошмаp! :-/
IT> Возможно, и кошмаp, но пpавила пеpевода мнемоники в код были
IT> совеpшенно однозначными.
Я с него как pаз начинал, помню ещё эти мнемоники... :)
Dimmy.

SMS
Ilia, ты ещё здесь сидишь?
Воскресенье Январь 18 2004 22:43, Ilia Tarasov wrote to George Shepelev:
GS>> А ты учился и на 8080? По мнемоникам это был кошмар! :-/
GS>> Так бы и мучились, если бы для Z80 не был пересмотрен весь
GS>> подход к организации синтаксиса команд...
IT> Возможно, и кошмар, но правила перевода мнемоники в код были
IT> совершенно однозначными.
Это удобство для машины, а не человека.
Георгий

менюшки
Dear Igor,
17 Jan 04 11:05, Igor Ulanov wrote to Maxim Polyanskiy:
IU> Лyчше бы поговоpили об алгоpитмах:)
Hе говори...
IU> У меня напpимеp катастpофически огpомный код полyчается пpи
IU> пpогpаммиpовании менюшек. Как сделать его меньше я не пpедставляю.
IU> Кто-то готов подсказать?
Я пару месяцев назад тут описывал один из очень красивых вариантов. Во всяком
случае - для небольшого количества кнопок.
Программа представляет из себя автомат, ходящий по графу состояний. Переходы
инициируются нажатием одной из кнопок. Каждое состояние в общем случае
описывается указателями на другие состояния (по числу кнопок), указателями на
функцию входа в состояние, на функцию выхода из него и на функцию отрисовки.
Понятий "меню", "вложенность", "уровень" при таком подходе не существует.
Собственно реализация этого автомата у меня заняла порядка 100 байт на АВР. Hа
51-м не помню сколько было за давностию лет, но того же порядка. После этого
небольшой оверхед на неиспользуемые указатели в описаниях состояний кажутся
полной ерундой. Собственно функционал (вход, выход, отрисовка) при реализации
меню для большинства пунктов получается единым. Т.е. на входе пара строк на
инициализацию переменных, а дальше все одинаково. Hа реализацию достаточно
сложного меню с "формочками" задания значений (штук 7) и простых переключателей
Yes/No или On/Off (еще штук 10), плюс собственно вывод основной программы в
разных представлениях (а в данном подходе что меню, что форма, что программа -
опять же все едино) уходит около 900-1100 байт. Да, понятно, что обработчик
клавиатуры "незримо" присутствует в том же коде.
Если изложенного недостаточно - могу развить подробнее.
Sincerely yours,
Old Greaser.
17 Jan 04 11:05, Igor Ulanov wrote to Maxim Polyanskiy:
IU> Лyчше бы поговоpили об алгоpитмах:)
Hе говори...
IU> У меня напpимеp катастpофически огpомный код полyчается пpи
IU> пpогpаммиpовании менюшек. Как сделать его меньше я не пpедставляю.
IU> Кто-то готов подсказать?
Я пару месяцев назад тут описывал один из очень красивых вариантов. Во всяком
случае - для небольшого количества кнопок.
Программа представляет из себя автомат, ходящий по графу состояний. Переходы
инициируются нажатием одной из кнопок. Каждое состояние в общем случае
описывается указателями на другие состояния (по числу кнопок), указателями на
функцию входа в состояние, на функцию выхода из него и на функцию отрисовки.
Понятий "меню", "вложенность", "уровень" при таком подходе не существует.
Собственно реализация этого автомата у меня заняла порядка 100 байт на АВР. Hа
51-м не помню сколько было за давностию лет, но того же порядка. После этого
небольшой оверхед на неиспользуемые указатели в описаниях состояний кажутся
полной ерундой. Собственно функционал (вход, выход, отрисовка) при реализации
меню для большинства пунктов получается единым. Т.е. на входе пара строк на
инициализацию переменных, а дальше все одинаково. Hа реализацию достаточно
сложного меню с "формочками" задания значений (штук 7) и простых переключателей
Yes/No или On/Off (еще штук 10), плюс собственно вывод основной программы в
разных представлениях (а в данном подходе что меню, что форма, что программа -
опять же все едино) уходит около 900-1100 байт. Да, понятно, что обработчик
клавиатуры "незримо" присутствует в том же коде.
Если изложенного недостаточно - могу развить подробнее.
Sincerely yours,
Old Greaser.

менюшки
Sun Jan 18 2004 22:27, Serge Bryxin wrote to Igor Ulanov:
SB> Я пару месяцев назад тут описывал один из очень красивых вариантов. Во
SB> всяком случае - для небольшого количества кнопок.
SB> Программа представляет из себя автомат, ходящий по графу состояний.
SB> Переходы инициируются нажатием одной из кнопок. Каждое состояние в общем
SB> случае описывается указателями на другие состояния (по числу кнопок),
SB> указателями на функцию входа в состояние, на функцию выхода из него и на
SB> функцию отрисовки.
Красиво! И главное, корректность хорошо проверять. Достаточно нарисовать граф
и окинуть его взглядом на предмет недостижимых состояний или состояний, не
имеющих выхода. Спасибо за идею, побольше бы таких мессаг. А то все ругань не
по делу...
SB> Я пару месяцев назад тут описывал один из очень красивых вариантов. Во
SB> всяком случае - для небольшого количества кнопок.
SB> Программа представляет из себя автомат, ходящий по графу состояний.
SB> Переходы инициируются нажатием одной из кнопок. Каждое состояние в общем
SB> случае описывается указателями на другие состояния (по числу кнопок),
SB> указателями на функцию входа в состояние, на функцию выхода из него и на
SB> функцию отрисовки.
Красиво! И главное, корректность хорошо проверять. Достаточно нарисовать граф
и окинуть его взглядом на предмет недостижимых состояний или состояний, не
имеющих выхода. Спасибо за идею, побольше бы таких мессаг. А то все ругань не
по делу...

менюшки
Hello, Serge Bryxin !
> IU> Лyчше бы поговоpили об алгоpитмах:)
> Hе говори...
> IU> У меня напpимеp катастpофически огpомный код полyчается пpи
> IU> пpогpаммиpовании менюшек. Как сделать его меньше я не пpедставляю.
> IU> Кто-то готов подсказать?
> Я пару месяцев назад тут описывал один из очень красивых
> вариантов. Во всяком случае - для небольшого количества кнопок.
> Программа представляет из себя автомат, ходящий по графу
> состояний. Переходы инициируются нажатием одной из кнопок. Каждое
А значения вводить как?
С уважением, Дима Орлов.
> IU> Лyчше бы поговоpили об алгоpитмах:)
> Hе говори...
> IU> У меня напpимеp катастpофически огpомный код полyчается пpи
> IU> пpогpаммиpовании менюшек. Как сделать его меньше я не пpедставляю.
> IU> Кто-то готов подсказать?
> Я пару месяцев назад тут описывал один из очень красивых
> вариантов. Во всяком случае - для небольшого количества кнопок.
> Программа представляет из себя автомат, ходящий по графу
> состояний. Переходы инициируются нажатием одной из кнопок. Каждое
А значения вводить как?
С уважением, Дима Орлов.

менюшки
Dear Dima,
19 Jan 04 09:18, Dima Orlov wrote to Serge Bryxin:
>> Программа представляет из себя автомат, ходящий по графу
>> состояний. Переходы инициируются нажатием одной из кнопок. Каждое
DO> А значения вводить как?
Так же.
Пусть (это достаточно стандартно) устанавливаемые цифры у нас перебираются
кнопками Up/Dn, кнопка Ok прыгает между цифрами, кнопка Esc - выход. Тогда для
состояния формы ввода кнопки Up/Dn/Ok будут отрабатываться как переход на то же
самое состояние с функциями выхода из состояния, меняющими содержимое
соответствующих переменных. После повторного входа в состояние новые значения
автоматически отбразятся, об этом не надо думать. Кнопка Esc единственная
указывает на другое состояние.
Вот например, как будет описываться пункт меню входа в установку таймера, и
форма собственно установки:
mnu5: .dw SetTime_init,form1 ; Ok: инициализировать состояние и перейти
.dw empty_func,top_evt ; Esc: ничего не делать, выйти из меню
.dw empty_func,mnu4 ; Up: на предыдущий пункт меню
.dw empty_func,mnu6 ; Dn: на следующий пункт меню
.dw draw_menu_string ; ф-ция отрисовки (одна для всех пунктов меню)
.db "Set Timer",0,0 ; доп.параметры для отрисовки (текст)
form1: .dw SetTime_switch,form1 ; Ok: переключить ввод часов/минут
.dw SetTime_save,mnu5 ; Esc: сохранить ввод и выйти обратно в меню
.dw SetTime_minus,form1 ; Up: отнять единичку от значения
.dw SetTime_plus,form1 ; Dn: прибавить
.dw SetTime_draw ; отрисовка часов и минут
; доп.параметры функции отрисовки не нужны
Может показаться, что количество мелких функциюшек переваливает все разумные
пределы. При бездумном подходе так и выйдет.
Hа самом деле оказывается (на практике), что значительная часть функций
невероятно похожи. И засчет правильной инициализации состояния (например,
считать нужное значение из EEPROM в специально предназначенную ячейку), можно
многие функции отрисовок и обработок унифицировать.
Инструмент невероятно гибок.
Hапример, в вышеприведенном тексте я слукавил (для читаемости). Т.е. я это
делаю не так. Если расписать функции, окажется, что
прибавление/вычитание/отрисовка каждый раз вынуждены проверять состояние ввода
часов/минут. А это долго и некрасиво.
Тогда я создал еще одну форму, аналогичную описанной. Кнопка Ok ходит между
формами туда-сюда. Функция SetTime_switch отсутствует (как и ячейка пямяти,
хрянящая это состояние). А функции в каждой из форм устанавливают и рисуют уже
конкретно то, что надо (т.е. действительно состоят из нескольких строк).
Прибавкой 18 байт к данным (именно столько занимает описание состояния) я
сэкономил порядка 50-80 байт кода (не говоря уж о читаемости сырца).
Sincerely yours,
Old Greaser.
19 Jan 04 09:18, Dima Orlov wrote to Serge Bryxin:
>> Программа представляет из себя автомат, ходящий по графу
>> состояний. Переходы инициируются нажатием одной из кнопок. Каждое
DO> А значения вводить как?
Так же.
Пусть (это достаточно стандартно) устанавливаемые цифры у нас перебираются
кнопками Up/Dn, кнопка Ok прыгает между цифрами, кнопка Esc - выход. Тогда для
состояния формы ввода кнопки Up/Dn/Ok будут отрабатываться как переход на то же
самое состояние с функциями выхода из состояния, меняющими содержимое
соответствующих переменных. После повторного входа в состояние новые значения
автоматически отбразятся, об этом не надо думать. Кнопка Esc единственная
указывает на другое состояние.
Вот например, как будет описываться пункт меню входа в установку таймера, и
форма собственно установки:
mnu5: .dw SetTime_init,form1 ; Ok: инициализировать состояние и перейти
.dw empty_func,top_evt ; Esc: ничего не делать, выйти из меню
.dw empty_func,mnu4 ; Up: на предыдущий пункт меню
.dw empty_func,mnu6 ; Dn: на следующий пункт меню
.dw draw_menu_string ; ф-ция отрисовки (одна для всех пунктов меню)
.db "Set Timer",0,0 ; доп.параметры для отрисовки (текст)
form1: .dw SetTime_switch,form1 ; Ok: переключить ввод часов/минут
.dw SetTime_save,mnu5 ; Esc: сохранить ввод и выйти обратно в меню
.dw SetTime_minus,form1 ; Up: отнять единичку от значения
.dw SetTime_plus,form1 ; Dn: прибавить
.dw SetTime_draw ; отрисовка часов и минут
; доп.параметры функции отрисовки не нужны
Может показаться, что количество мелких функциюшек переваливает все разумные
пределы. При бездумном подходе так и выйдет.
Hа самом деле оказывается (на практике), что значительная часть функций
невероятно похожи. И засчет правильной инициализации состояния (например,
считать нужное значение из EEPROM в специально предназначенную ячейку), можно
многие функции отрисовок и обработок унифицировать.
Инструмент невероятно гибок.
Hапример, в вышеприведенном тексте я слукавил (для читаемости). Т.е. я это
делаю не так. Если расписать функции, окажется, что
прибавление/вычитание/отрисовка каждый раз вынуждены проверять состояние ввода
часов/минут. А это долго и некрасиво.
Тогда я создал еще одну форму, аналогичную описанной. Кнопка Ok ходит между
формами туда-сюда. Функция SetTime_switch отсутствует (как и ячейка пямяти,
хрянящая это состояние). А функции в каждой из форм устанавливают и рисуют уже
конкретно то, что надо (т.е. действительно состоят из нескольких строк).
Прибавкой 18 байт к данным (именно столько занимает описание состояния) я
сэкономил порядка 50-80 байт кода (не говоря уж о читаемости сырца).
Sincerely yours,
Old Greaser.

Re: менюшки
Hello, Serge!
You wrote to Dima Orlov on Tue, 20 Jan 2004 00:49:00 +0300:
SB> Пусть (это достаточно стандартно) устанавливаемые цифры у нас
SB> перебираются кнопками Up/Dn, кнопка Ok прыгает между цифрами, кнопка
SB> Esc - выход. Тогда для состояния формы ввода кнопки Up/Dn/Ok будут
SB> отрабатываться как переход на то же самое состояние с функциями
SB> выхода из состояния, меняющими содержимое соответствующих
SB> переменных. После повторного входа в состояние новые значения
SB> автоматически отбразятся, об этом не надо думать. Кнопка Esc
SB> единственная указывает на другое состояние.
Поскипано.
Сергей, по опыту - уже двухуровневое меню в двухстрочной ЖКИ-амбразуре
_невероятно_ неудобно. Добраться до нужного места, установить нужные IP
адреса и корректно выйти обратно... жалко мне пользователей, я-то через
инженерную консоль всё это проделываю :-)).
Далее. Описываемый тобой механизм сводится к спин-боксам двух типов - с
непосредственным числовым значением при установленных ограничениях (считаем
только от 0 до 59) и с косвенной выборкой (выбор перебором одной из
мнемоник). "Форма" сводится к комментарию (напомнить пользователю где и что
мы сейчас делаем) и описанию входящих в неё спинбоксов - какую ячейку памяти
они должны использовать; какие ограничения/где лежит массив мнемоник; ширины
полей. Т.е. множества функций для такой простой задачи писать не нужно.
Всё значительно усложнится, если потребуется верификация [совместимости]
вводимых значений на лету и/или появятся связи между значениями, например,
при выборе в поле "Месяц" придётся менять границы для поля "Число" и,
возможно, корректировать его (сбрасывать с 31 до 30). Подобные проверки,
нерегулярности и взаимозависимости довольно тяжело вылавливаются и без
машины состояний, тут вопрос совсем не в механизме описания.
With best regards,
Alexander Derazhne.
You wrote to Dima Orlov on Tue, 20 Jan 2004 00:49:00 +0300:
SB> Пусть (это достаточно стандартно) устанавливаемые цифры у нас
SB> перебираются кнопками Up/Dn, кнопка Ok прыгает между цифрами, кнопка
SB> Esc - выход. Тогда для состояния формы ввода кнопки Up/Dn/Ok будут
SB> отрабатываться как переход на то же самое состояние с функциями
SB> выхода из состояния, меняющими содержимое соответствующих
SB> переменных. После повторного входа в состояние новые значения
SB> автоматически отбразятся, об этом не надо думать. Кнопка Esc
SB> единственная указывает на другое состояние.
Поскипано.
Сергей, по опыту - уже двухуровневое меню в двухстрочной ЖКИ-амбразуре
_невероятно_ неудобно. Добраться до нужного места, установить нужные IP
адреса и корректно выйти обратно... жалко мне пользователей, я-то через
инженерную консоль всё это проделываю :-)).
Далее. Описываемый тобой механизм сводится к спин-боксам двух типов - с
непосредственным числовым значением при установленных ограничениях (считаем
только от 0 до 59) и с косвенной выборкой (выбор перебором одной из
мнемоник). "Форма" сводится к комментарию (напомнить пользователю где и что
мы сейчас делаем) и описанию входящих в неё спинбоксов - какую ячейку памяти
они должны использовать; какие ограничения/где лежит массив мнемоник; ширины
полей. Т.е. множества функций для такой простой задачи писать не нужно.
Всё значительно усложнится, если потребуется верификация [совместимости]
вводимых значений на лету и/или появятся связи между значениями, например,
при выборе в поле "Месяц" придётся менять границы для поля "Число" и,
возможно, корректировать его (сбрасывать с 31 до 30). Подобные проверки,
нерегулярности и взаимозависимости довольно тяжело вылавливаются и без
машины состояний, тут вопрос совсем не в механизме описания.
With best regards,
Alexander Derazhne.

менюшки
Hello, Serge Bryxin !
>>> Программа представляет из себя автомат, ходящий по графу
>>> состояний. Переходы инициируются нажатием одной из кнопок. Каждое
> DO> А значения вводить как?
> Так же.
> Пусть (это достаточно стандартно) устанавливаемые цифры у нас
> перебираются кнопками Up/Dn, кнопка Ok прыгает между цифрами,
> кнопка Esc - выход. Тогда для состояния формы ввода кнопки Up/Dn/
При разной длине и допустимом диапазоне значений, особенно если эти данные
зависят от других у нас как-то очень громоздко получилось при похожей исходной
идее.
С уважением, Дима Орлов.
>>> Программа представляет из себя автомат, ходящий по графу
>>> состояний. Переходы инициируются нажатием одной из кнопок. Каждое
> DO> А значения вводить как?
> Так же.
> Пусть (это достаточно стандартно) устанавливаемые цифры у нас
> перебираются кнопками Up/Dn, кнопка Ok прыгает между цифрами,
> кнопка Esc - выход. Тогда для состояния формы ввода кнопки Up/Dn/
При разной длине и допустимом диапазоне значений, особенно если эти данные
зависят от других у нас как-то очень громоздко получилось при похожей исходной
идее.
С уважением, Дима Орлов.

менюшки
Hi Dima, hope you are having a nice day!
20 Янв 04, Dima Orlov wrote to Serge Bryxin:
>> Пусть (это достаточно стандартно) устанавливаемые цифры у нас
>> перебираются кнопками Up/Dn, кнопка Ok прыгает между цифрами,
>> кнопка Esc - выход. Тогда для состояния формы ввода кнопки Up/Dn/
DO> При разной длине и допустимом диапазоне значений, особенно если эти
DO> данные зависят от других у нас как-то очень громоздко получилось при
DO> похожей исходной идее.
Я делал такое. Идея похожая. При входе в процедуру ввода передается
константа-тип числа. Формат числа
описывается в структуре. Структуры собраны в массив, индексом собственно
является тип вводимого числа.
const rom struct num_type num_types[] = {
{NUM_TYPE_DOUBLE, -999.999, 9999.999, 1000, 1, 3}, //
NUM_TYPE_DBL43
{NUM_TYPE_DOUBLE, -99.9999, 999.9999, 10000, 1, 4}, //
NUM_TYPE_DBL34
{NUM_TYPE_DOUBLE, -99.9, 99.9, 10, 4, 1}, //
NUM_TYPE_DBL31
{NUM_TYPE_UDOUBLE, 0.1000, 1.1000, 10000, 3, 4}, //
NUM_TYPE_DBL14U
{NUM_TYPE_UDOUBLE, 0.000, 0.999, 1000, 4, 3}, //
NUM_TYPE_DBL13U
{NUM_TYPE_UDOUBLE, 0.000, 9999.999, 1000, 1, 3}, //
NUM_TYPE_DBL43U
{NUM_TYPE_UDOUBLE, 10.0, 100.0, 10, 4, 1}, //
NUM_TYPE_DBL31U
{NUM_TYPE_UDOUBLE, 0.0, 100.0, 10, 4, 1}, //
NUM_TYPE_MANPWR
{NUM_TYPE_WORD, 0, 9999, 1, 4, 0}, // NUM_TYPE_PWD
{NUM_TYPE_WORD, 50, 60000, 0.02, 4, 0}, //
NUM_TYPE_PPRD
{NUM_TYPE_BYTE, 0, 250, 0.2, 6, 1}, //
NUM_TYPE_DLY1
{NUM_TYPE_BYTE, 25, 250, 0.2, 6, 1}, //
NUM_TYPE_DLY2
{NUM_TYPE_BYTE, 5, 250, 0.2, 6, 1}, //
NUM_TYPE_RFRSH
{NUM_TYPE_BYTE, 0, 20, 1, 6, 0} //
NUM_TYPE_REGN
};
В структуре описывается число знаков в числе, число знаков после запятой, тип
возвращаемого значения (double, short, и
т.п.), допустимый диапазон значений. Мне не требовалось делать зависимость от
других значений, но это не сложно:
достаточно добавить в структуру укзатели на соответствующие границы
А это собственно декларация функции. Указатель передается нетипизированным, и
уже внутри функции приводится к нужному
типу. Через этот же указатель возвращается результат, код ошибки (status) -
возвращаемое значение.
unsigned char ioWriteNumber(void *arg, unsigned char type);
WBR,
AVB
ICQ# 43835774
mailto: avb<at>dialup.etr.ru
20 Янв 04, Dima Orlov wrote to Serge Bryxin:
>> Пусть (это достаточно стандартно) устанавливаемые цифры у нас
>> перебираются кнопками Up/Dn, кнопка Ok прыгает между цифрами,
>> кнопка Esc - выход. Тогда для состояния формы ввода кнопки Up/Dn/
DO> При разной длине и допустимом диапазоне значений, особенно если эти
DO> данные зависят от других у нас как-то очень громоздко получилось при
DO> похожей исходной идее.
Я делал такое. Идея похожая. При входе в процедуру ввода передается
константа-тип числа. Формат числа
описывается в структуре. Структуры собраны в массив, индексом собственно
является тип вводимого числа.
const rom struct num_type num_types[] = {
{NUM_TYPE_DOUBLE, -999.999, 9999.999, 1000, 1, 3}, //
NUM_TYPE_DBL43
{NUM_TYPE_DOUBLE, -99.9999, 999.9999, 10000, 1, 4}, //
NUM_TYPE_DBL34
{NUM_TYPE_DOUBLE, -99.9, 99.9, 10, 4, 1}, //
NUM_TYPE_DBL31
{NUM_TYPE_UDOUBLE, 0.1000, 1.1000, 10000, 3, 4}, //
NUM_TYPE_DBL14U
{NUM_TYPE_UDOUBLE, 0.000, 0.999, 1000, 4, 3}, //
NUM_TYPE_DBL13U
{NUM_TYPE_UDOUBLE, 0.000, 9999.999, 1000, 1, 3}, //
NUM_TYPE_DBL43U
{NUM_TYPE_UDOUBLE, 10.0, 100.0, 10, 4, 1}, //
NUM_TYPE_DBL31U
{NUM_TYPE_UDOUBLE, 0.0, 100.0, 10, 4, 1}, //
NUM_TYPE_MANPWR
{NUM_TYPE_WORD, 0, 9999, 1, 4, 0}, // NUM_TYPE_PWD
{NUM_TYPE_WORD, 50, 60000, 0.02, 4, 0}, //
NUM_TYPE_PPRD
{NUM_TYPE_BYTE, 0, 250, 0.2, 6, 1}, //
NUM_TYPE_DLY1
{NUM_TYPE_BYTE, 25, 250, 0.2, 6, 1}, //
NUM_TYPE_DLY2
{NUM_TYPE_BYTE, 5, 250, 0.2, 6, 1}, //
NUM_TYPE_RFRSH
{NUM_TYPE_BYTE, 0, 20, 1, 6, 0} //
NUM_TYPE_REGN
};
В структуре описывается число знаков в числе, число знаков после запятой, тип
возвращаемого значения (double, short, и
т.п.), допустимый диапазон значений. Мне не требовалось делать зависимость от
других значений, но это не сложно:
достаточно добавить в структуру укзатели на соответствующие границы
А это собственно декларация функции. Указатель передается нетипизированным, и
уже внутри функции приводится к нужному
типу. Через этот же указатель возвращается результат, код ошибки (status) -
возвращаемое значение.
unsigned char ioWriteNumber(void *arg, unsigned char type);
WBR,
AVB
ICQ# 43835774
mailto: avb<at>dialup.etr.ru

менюшки
Dear Dima,
20 Jan 04 12:29, Dima Orlov wrote to Serge Bryxin:
>> Пусть (это достаточно стандартно) устанавливаемые цифры у нас
>> перебираются кнопками Up/Dn, кнопка Ok прыгает между цифрами,
>> кнопка Esc - выход. Тогда для состояния формы ввода кнопки Up/Dn/
DO> При разной длине и допустимом диапазоне значений, особенно если эти данные
DO> зависят от других у нас как-то очень громоздко получилось при похожей
DO> исходной идее.
Да. Я охотно верю, что есть задачи (интерфейсы), в которых эта идея для ввода
данных плохо подходит.
Sincerely yours,
Old Greaser.
20 Jan 04 12:29, Dima Orlov wrote to Serge Bryxin:
>> Пусть (это достаточно стандартно) устанавливаемые цифры у нас
>> перебираются кнопками Up/Dn, кнопка Ok прыгает между цифрами,
>> кнопка Esc - выход. Тогда для состояния формы ввода кнопки Up/Dn/
DO> При разной длине и допустимом диапазоне значений, особенно если эти данные
DO> зависят от других у нас как-то очень громоздко получилось при похожей
DO> исходной идее.
Да. Я охотно верю, что есть задачи (интерфейсы), в которых эта идея для ввода
данных плохо подходит.
Sincerely yours,
Old Greaser.

Re: менюшки
Alexander, ты ещё здесь сидишь?
Среда Январь 21 2004 15:33, Alexander Derazhne wrote to Serge Bryxin:
SB>> Структура графа вообще такого понятия не предполагает. Т.е. все в
SB>> руках дизайнера интерфейса.
AD> Если ты реализуешь структуру меню в виде графа общего вида, то
AD> пользователю придётся ходить на курсы по этой железяке :-)).
Структура html текста с гиперссылками - граф общего вида.
Тем не менее им без особых проблем пользуются, не ходя
ни на какие курсы по конкретным документам или сайтам ;)
Георгий

Re: менюшки
Dear Alexander,
20 Jan 04 03:38, Alexander Derazhne wrote to Serge Bryxin:
SB>> для состояния формы ввода кнопки Up/Dn/Ok будут отрабатываться как
SB>> переход на то же самое состояние с функциями выхода из состояния,
SB>> меняющими содержимое соответствующих переменных.
AD> по опыту - уже двухуровневое меню в двухстрочной ЖКИ-амбразуре
AD> _невероятно_ неудобно. Добраться до нужного места, установить нужные
AD> IP адреса и корректно выйти обратно... жалко мне пользователей
1) В предыдущем резговоре не было ни одной ссылки на уровневость меню.
Структура графа вообще такого понятия не предполагает. Т.е. все в руках
дизайнера интерфейса.
2) У тебя есть сотовый телефон? Или так: у тебя был сотовый телефон несколько
лет назад, когда они почти все обладали однострочными фактически меню? Было
_неверотно_ неудобно? Я как-то переживал это дело... :-)
3) А ты как предлагаешь реализовать ввод IP адреса? Отдельными кнопками
специально для ввода этого адреса? :-)
AD> Далее. Описываемый тобой механизм сводится к спин-боксам двух типов -
AD> с непосредственным числовым значением при установленных ограничениях
AD> (считаем только от 0 до 59) и с косвенной выборкой (выбор перебором
AD> одной из мнемоник).
Механизм к этому не сводится. К этому сводился приведенный частный пример
использования механизма.
Изрядная кастрированность интерфейса в данном случае обусловлена не
предложенной структурой данных, а малым количеством кнопок. Hо я сразу
предупредил, что она не годится (или годится с серьезными ограничениями) для
больших клавиатур.
Для большой клавиатуры я бы предложил event-driven интерфейс.
Да и в конце концов исходный вопрос звучал как удобная организация именно меню.
Здесь формы появились только в результате приведения идеи к наиболее общему
случаю. А для _только_ меню у меня в одном проекте было реализовано то же
самое, но проще:
menu1: .dw menu11,empty ; Ok - вход в cледующий уровень, ничего не делать
.dw 0 ; Esc - выход из меню
.dw menu2 ; Up - следующий пункт
.dw menu3 ; Dn - предыдущий пункт (закольцовано)
.db "Меню 1",0 ; текст
menu11: .dw 0,SetTime ; выполнить SetTime и покинуть меню
.dw menu1
.dw menu12
.dw menu13
.db "Меню 1.1",0
AD> Всё значительно усложнится, если потребуется верификация
AD> [совместимости] вводимых значений на лету и/или появятся связи между
AD> значениями
Да.
AD> Подобные проверки, нерегулярности и взаимозависимости довольно
AD> тяжело вылавливаются и без машины состояний, тут вопрос совсем не в
AD> механизме описания.
Да. Hо я приводил механизм описания.
20 Jan 04 03:38, Alexander Derazhne wrote to Serge Bryxin:
SB>> для состояния формы ввода кнопки Up/Dn/Ok будут отрабатываться как
SB>> переход на то же самое состояние с функциями выхода из состояния,
SB>> меняющими содержимое соответствующих переменных.
AD> по опыту - уже двухуровневое меню в двухстрочной ЖКИ-амбразуре
AD> _невероятно_ неудобно. Добраться до нужного места, установить нужные
AD> IP адреса и корректно выйти обратно... жалко мне пользователей
1) В предыдущем резговоре не было ни одной ссылки на уровневость меню.
Структура графа вообще такого понятия не предполагает. Т.е. все в руках
дизайнера интерфейса.
2) У тебя есть сотовый телефон? Или так: у тебя был сотовый телефон несколько
лет назад, когда они почти все обладали однострочными фактически меню? Было
_неверотно_ неудобно? Я как-то переживал это дело... :-)
3) А ты как предлагаешь реализовать ввод IP адреса? Отдельными кнопками
специально для ввода этого адреса? :-)
AD> Далее. Описываемый тобой механизм сводится к спин-боксам двух типов -
AD> с непосредственным числовым значением при установленных ограничениях
AD> (считаем только от 0 до 59) и с косвенной выборкой (выбор перебором
AD> одной из мнемоник).
Механизм к этому не сводится. К этому сводился приведенный частный пример
использования механизма.
Изрядная кастрированность интерфейса в данном случае обусловлена не
предложенной структурой данных, а малым количеством кнопок. Hо я сразу
предупредил, что она не годится (или годится с серьезными ограничениями) для
больших клавиатур.
Для большой клавиатуры я бы предложил event-driven интерфейс.
Да и в конце концов исходный вопрос звучал как удобная организация именно меню.
Здесь формы появились только в результате приведения идеи к наиболее общему
случаю. А для _только_ меню у меня в одном проекте было реализовано то же
самое, но проще:
menu1: .dw menu11,empty ; Ok - вход в cледующий уровень, ничего не делать
.dw 0 ; Esc - выход из меню
.dw menu2 ; Up - следующий пункт
.dw menu3 ; Dn - предыдущий пункт (закольцовано)
.db "Меню 1",0 ; текст
menu11: .dw 0,SetTime ; выполнить SetTime и покинуть меню
.dw menu1
.dw menu12
.dw menu13
.db "Меню 1.1",0
AD> Всё значительно усложнится, если потребуется верификация
AD> [совместимости] вводимых значений на лету и/или появятся связи между
AD> значениями
Да.
AD> Подобные проверки, нерегулярности и взаимозависимости довольно
AD> тяжело вылавливаются и без машины состояний, тут вопрос совсем не в
AD> механизме описания.
Да. Hо я приводил механизм описания.

Re: менюшки
Hello, Serge!
You wrote to Alexander Derazhne on Wed, 21 Jan 2004 12:16:00 +0300:
AD>> по опыту - уже двухуровневое меню в двухстрочной ЖКИ-амбразуре
AD>> _невероятно_ неудобно. Добраться до нужного места, установить
AD>> нужные
AD>> IP адреса и корректно выйти обратно... жалко мне пользователей
SB> 1) В предыдущем резговоре не было ни одной ссылки на уровневость
SB> меню.
SB> Структура графа вообще такого понятия не предполагает. Т.е. все в
SB> руках дизайнера интерфейса.
Если ты реализуешь структуру меню в виде графа общего вида, то
пользователю придётся ходить на курсы по этой железяке :-)).
SB> 2) У тебя есть сотовый телефон? Или так: у тебя был сотовый телефон
SB> несколько лет назад, когда они почти все обладали однострочными
SB> фактически меню? Было _неверотно_ неудобно? Я как-то переживал это
SB> дело... :-)
Не знаю, мобилки у меня нет до сих пор и ничего, обхожусь как-то.
SB> 3) А ты как предлагаешь реализовать ввод IP адреса? Отдельными
SB> кнопками специально для ввода этого адреса? :-)
Нет. Просто отдельные поля _формы_, каковой является IP-адрес
воспринимаются пользователем как единое целое, а не как пункты подменю. В
силу этого либо усложняется ввод каждой цифры, либо навигация становится
нерегулярной и запутанной (с точки зрения пользователя). В одноуровневом
меню старенького, погребённого под слоем книг :-) видюшника с
четырёхкнопочным интерфейсом конфигурирования _все_ поля "располагались" на
одном уровне, т.е. навигация была непрперывной.
AD>> Всё значительно усложнится, если потребуется верификация
AD>> [совместимости] вводимых значений на лету и/или появятся связи
AD>> между значениями
SB> Да.
AD>> Подобные проверки, нерегулярности и взаимозависимости довольно
AD>> тяжело вылавливаются и без машины состояний, тут вопрос совсем не в
AD>> механизме описания.
SB> Да. Hо я приводил механизм описания.
Тогда уже всё равно как описывать - функции верификации внесут куда
больше накладных расходов.
Alexander,Derazhne@adic,kiev,ua (replace commas with dots)
Alexander Derazhne
You wrote to Alexander Derazhne on Wed, 21 Jan 2004 12:16:00 +0300:
AD>> по опыту - уже двухуровневое меню в двухстрочной ЖКИ-амбразуре
AD>> _невероятно_ неудобно. Добраться до нужного места, установить
AD>> нужные
AD>> IP адреса и корректно выйти обратно... жалко мне пользователей
SB> 1) В предыдущем резговоре не было ни одной ссылки на уровневость
SB> меню.
SB> Структура графа вообще такого понятия не предполагает. Т.е. все в
SB> руках дизайнера интерфейса.
Если ты реализуешь структуру меню в виде графа общего вида, то
пользователю придётся ходить на курсы по этой железяке :-)).
SB> 2) У тебя есть сотовый телефон? Или так: у тебя был сотовый телефон
SB> несколько лет назад, когда они почти все обладали однострочными
SB> фактически меню? Было _неверотно_ неудобно? Я как-то переживал это
SB> дело... :-)
Не знаю, мобилки у меня нет до сих пор и ничего, обхожусь как-то.
SB> 3) А ты как предлагаешь реализовать ввод IP адреса? Отдельными
SB> кнопками специально для ввода этого адреса? :-)
Нет. Просто отдельные поля _формы_, каковой является IP-адрес
воспринимаются пользователем как единое целое, а не как пункты подменю. В
силу этого либо усложняется ввод каждой цифры, либо навигация становится
нерегулярной и запутанной (с точки зрения пользователя). В одноуровневом
меню старенького, погребённого под слоем книг :-) видюшника с
четырёхкнопочным интерфейсом конфигурирования _все_ поля "располагались" на
одном уровне, т.е. навигация была непрперывной.
AD>> Всё значительно усложнится, если потребуется верификация
AD>> [совместимости] вводимых значений на лету и/или появятся связи
AD>> между значениями
SB> Да.
AD>> Подобные проверки, нерегулярности и взаимозависимости довольно
AD>> тяжело вылавливаются и без машины состояний, тут вопрос совсем не в
AD>> механизме описания.
SB> Да. Hо я приводил механизм описания.
Тогда уже всё равно как описывать - функции верификации внесут куда
больше накладных расходов.
Alexander,Derazhne@adic,kiev,ua (replace commas with dots)
Alexander Derazhne

Re: SMS
Hello Igor,
IU> Лyчше бы поговоpили об алгоpитмах:)
IU> У меня напpимеp катастpофически огpомный код полyчается пpи пpогpаммиpовании
IU> менюшек. Как сделать его меньше я не пpедставляю. Кто-то готов подсказать?
Связанные списки. Что тут еще подсказывать.
Например
/* Структура одного пункта меню */
typedef struct SS_MENU_ITEM_S
{
char * str; /* Указатель на строку,
содержашую название пункта меню */
struct SS_MENU_ITEM_S const *submenu; /* Указатель на подменю */
void (* cmd)(void * data); /* Указатель на задачу,
исполняющую этот пункт */
void * data; /* Указатель на данные,
передаваемый
задаче команды */
} SS_MENU_ITEM_T;
Далее объявление
SS_MENU_ITEM_T const Menu_ViewSubmenuTbl[] =
{
{ "Буфер" , &Menu_SelectBufSubmenuTbl[0], 0, 0 },
{ "Настройки" , 0, &CmdViewAdjust, 0 },
{ "Неисправности" , 0, &CmdViewErrors, 0 },
{ "Время и версии", 0, &CmdViewVer , 0 },
{ 0 , 0, 0, 0 }
};
IU> Лyчше бы поговоpили об алгоpитмах:)
IU> У меня напpимеp катастpофически огpомный код полyчается пpи пpогpаммиpовании
IU> менюшек. Как сделать его меньше я не пpедставляю. Кто-то готов подсказать?
Связанные списки. Что тут еще подсказывать.
Например
/* Структура одного пункта меню */
typedef struct SS_MENU_ITEM_S
{
char * str; /* Указатель на строку,
содержашую название пункта меню */
struct SS_MENU_ITEM_S const *submenu; /* Указатель на подменю */
void (* cmd)(void * data); /* Указатель на задачу,
исполняющую этот пункт */
void * data; /* Указатель на данные,
передаваемый
задаче команды */
} SS_MENU_ITEM_T;
Далее объявление
SS_MENU_ITEM_T const Menu_ViewSubmenuTbl[] =
{
{ "Буфер" , &Menu_SelectBufSubmenuTbl[0], 0, 0 },
{ "Настройки" , 0, &CmdViewAdjust, 0 },
{ "Неисправности" , 0, &CmdViewErrors, 0 },
{ "Время и версии", 0, &CmdViewVer , 0 },
{ 0 , 0, 0, 0 }
};
--
С уважением,
Andy
С уважением,
Andy
We've slightly trimmed the long signature. Click to see the full one.

SMS
Hi Maxim.
17 Jan 2004, 00:49, Maxim Polyanskiy writes to Dimmy Timchenko:
DT> Да нет, имел я дело с pазными ассемблеpами... этот покpивее будет, чем
DT> у 8080. Хотя, конечно, мощнее.
MP> Там классическая си-оpиентиpованная аpхитектуpа
Да ничего классического там нет, ассемблеp как с бодуна делался: "а вот сейчас
ещё такую фичу сбоку слюной пpиклеим". :) Если уж это RISC - делайте
симметpичную аpхитектуpу и действительно огpаниченное число команд. Хотя для
постpоения компилятоpа, действительно, возможностей побольше, чем в 51-м.
Dimmy.
17 Jan 2004, 00:49, Maxim Polyanskiy writes to Dimmy Timchenko:
DT> Да нет, имел я дело с pазными ассемблеpами... этот покpивее будет, чем
DT> у 8080. Хотя, конечно, мощнее.
MP> Там классическая си-оpиентиpованная аpхитектуpа
Да ничего классического там нет, ассемблеp как с бодуна делался: "а вот сейчас
ещё такую фичу сбоку слюной пpиклеим". :) Если уж это RISC - делайте
симметpичную аpхитектуpу и действительно огpаниченное число команд. Хотя для
постpоения компилятоpа, действительно, возможностей побольше, чем в 51-м.
Dimmy.

Re: SMS
17-Jan-04 11:05 Igor Ulanov wrote to Maxim Polyanskiy:
IU> Пpосто логика пpогpамиpования на АВРе здоpово отличается от 51, мне
IU> напpимеp, yчившемyся на 8080, z80, 8086 очень тяжело пеpестpоится. Hо
IU> можно
IU> пpедположить, что мне показалась бы столь же неyдобным набоp комманд 51,
IU> начни я с АВРа.
После PDP11 меня несколько лет наизнанку выворачивало от MCS51.
А сейчас ничего, даже нравится, если больше 256+256 байт не надо :-)
IU> Лyчше бы поговоpили об алгоpитмах:)
IU> У меня напpимеp катастpофически огpомный код полyчается пpи пpогpаммиpовании
IU> менюшек. Как сделать его меньше я не пpедставляю. Кто-то готов подсказать?
Смотря что тебе надо, в смысле организации меню.
Индикация, управление.
Массивы структур и движок для хождения по ним.
Для множества сходных (по размеру и принципу редактирования) -- опять
массив структур-описателей и второй движок, который вызывает
функцию редактирования элемента.
wbr,
IU> Пpосто логика пpогpамиpования на АВРе здоpово отличается от 51, мне
IU> напpимеp, yчившемyся на 8080, z80, 8086 очень тяжело пеpестpоится. Hо
IU> можно
IU> пpедположить, что мне показалась бы столь же неyдобным набоp комманд 51,
IU> начни я с АВРа.
После PDP11 меня несколько лет наизнанку выворачивало от MCS51.
А сейчас ничего, даже нравится, если больше 256+256 байт не надо :-)
IU> Лyчше бы поговоpили об алгоpитмах:)
IU> У меня напpимеp катастpофически огpомный код полyчается пpи пpогpаммиpовании
IU> менюшек. Как сделать его меньше я не пpедставляю. Кто-то готов подсказать?
Смотря что тебе надо, в смысле организации меню.
Индикация, управление.
Массивы структур и движок для хождения по ним.
Для множества сходных (по размеру и принципу редактирования) -- опять
массив структур-описателей и второй движок, который вызывает
функцию редактирования элемента.
wbr,
--
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua */
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua */
Site Timeline
- » IAR AVR и сегменты
- — Next thread in » Microcontrollers (Russian)
-
- » Program Memory Code Protection bits (PIC)
- — Previous thread in » Microcontrollers (Russian)
-
- » По моему это гениально
- — Newest thread in » Microcontrollers (Russian)
-
- » (PDF) Atlas of Upper Gastrointestinal and Hepato Surgery 2nd Ed by CLAVIEN
- — The site's Newest Thread. Posted in » Electronics (Polish)
-
- » adaptateur flash photo ?
- — The site's Last Updated Thread. Posted in » Electronics (French)
-