Моя работа

Я немного не в теме. А что P-CAD умеет работать под Linux?

> Я немного не в теме. А что P-CAD умеет работать под Linux?

Судя по некоторым деталям его окна, он просто запущен под вайном.

Кстати, а есть принципиальные преимущества у avra по сравнению с gas из binutils, собранного под архитектуру avr?

ЗЫ тоже делал некоторые устройства на avr-ках, только в качестве ассемблера использовал gas, а потом вообще на gcc перешёл (ИМХО писать на C гораздо удобнее, кроме случаев когда нужна жёсткая оптимизация).

Зачёт!

фигасе рабочих столов...

А можно скрипт для Concky ?

Наверное это удобно!

Зачет, тем не менее.

Нумерация рабочих столов начинается с 1, а последний - 0:)

> Кстати, а есть принципиальные преимущества у avra по сравнению с gas из binutils, собранного под архитектуру avr?

Принципиальное преимущество AVRA в том, что он позиционируется разработчиками, как замена стандартного AVRASM. Соответственно, совместим по формату исходников (с мелкими несущественными отличиями). Первоначально, переехав с Win, я AVRASM и использовал, под Wine. Но он вызывается довольно долго, ибо WINESERVER грузится, плюс ему просто так не передашь параметры в командной строке, надо изгаляться с конвертацией. А так - заменил имя исполнимого файла в скриптах, да пару строк в исходниках поправил.

> А можно скрипт для Concky ?

Да пожалуйста:

-------
background yes
font -monotype-arial-bold-r-normal--12-120-75-75-p-0-koi8-r
use_xft no
update_interval 2.0
total_run_times 0
own_window no
own_window_transparent yes
double_buffer yes
minimum_size 220 5
draw_shades no
draw_outline no
draw_borders no
draw_graph_borders yes
border_margin 6
border_width 1
default_color black
default_shade_color gray50
default_outline_color black
alignment top_right
gap_x 5
gap_y 5
no_buffers yes
uppercase no
cpu_avg_samples 1
net_avg_samples 2
override_utf8_locale no
use_spacer no
xmms_player bmp
TEXT
$alignc$sysname $kernel
${stippled_hr 2}
${color #3f3f3f}Время работы:$color$alignr$uptime
${color #3f3f3f}Заряд батареи:$color$alignr${apm_battery_life}
${color #3f3f3f}Загрузка системы:$color$alignr$loadavg
${color #3f3f3f}Использование процессора:$alignr$color$cpu%
${color #3f3f3f}Температура процессора:$alignr$color${acpitemp}°C
$color${stippled_hr 2}
${color #3f3f3f}Память:${color brown}$alignr$mem/$memmax - $memperc%
${membar 10}
${color #3f3f3f}Подкачка:${color brown}$alignr$swap/$swapmax - $swapperc%
${swapbar 10}
${color #3f3f3f}Процессов:${color brown} $processes$alignr${color #3f3f3f}Активных:${color brown} $running_processes
$color${stippled_hr 2}
$alignc${color #3f3f3f}Сеть Wi-Fi:
Приём:${color #7f007f} ${downspeedf ipw0} $alignr${color #3f3f3f}Передача:${color #00009f} ${upspeedf ipw0}
${color #3f3f3f}Всего принято:$alignr${totaldown ipw0}
${color #3f3f3f}Всего передано:$alignr${totalup ipw0}
${voffset 3}$alignc${color #3f3f3f}Сеть Ethernet:
Приём:${color #7f007f} ${downspeedf bfe0} $alignr${color #3f3f3f}Передача:${color #00009f} ${upspeedf bfe0}
${color #3f3f3f}Всего принято:$alignr${totaldown bfe0}
${color #3f3f3f}Всего передано:$alignr${totalup bfe0}
$color${stippled_hr 2}
$alignc${color #3f3f3f}Файловые системы:
${color}HDD:root $alignr${color #007f00}${fs_free /}/${fs_size /}
${fs_bar 10 /}
${color}HDD:usr $alignr${color #007f00}${fs_free /usr}/${fs_size /usr}
${fs_bar 10 /usr}
${color}HDD:data $alignr${color #007f00}${fs_free /mnt/data}/${fs_size /mnt/data}
${fs_bar 10 /mnt/data}
${if_mounted /mnt/usb}${color}USB-диск $alignr${color #007f00}${fs_free /mnt/usb}/${fs_size /mnt/usb}
${fs_bar 10 /mnt/usb}$endif
${if_mounted /mnt/sm}${color}SmartMedia $alignr${color #007f00}${fs_free /mnt/sm}/${fs_size /mnt/sm}
${fs_bar 10 /mnt/sm}$endif
${if_mounted /mnt/cdrom}${color}DVD/CD $alignr${color #007f00}${fs_size /mnt/cdrom}$endif

Насколько я понимаю - avrasm и avra - заброшены. так как почти никому не нужны.

если это настоящее разрешение монитора, то интересно было бы узнать, чем он лучше набора из двух или даже трёх мониторов с заведомо большим суммарным разрешением за ту же стоимость, для работы составной вариант был бы наверное оптимальнее, если конечно он не используется для просмотра HD фильмов...

> Насколько я понимаю - avrasm и avra - заброшены. так как почти никому не нужны.

Вы ошибаетесь. AVRASM2 - часть AvrStudio, каковой пакет живет и здравствует.

И потом - отличная подмена понятий: заброшены -> никому не нужны. Мне лично AVRA очень даже нужен. И если разработчики на него забили, я его сам до ума доведу, ибо GPL. Потом либо перешлю разработчикам изменения, если они проснутся, либо форкну (маловероятно, поскольку программер под PC из меня - так себе).

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

Чисто для справки - это 15.4" матрица моего ноутбука. :)

Пасибо за скриптик

Неужели дурацкий "научный калькулятор" удобнее xterm -e "bc -l" (/s/xterm/gnome-terminal, konsole, etc/) навешенного на шорткат?

>Вы ошибаетесь. AVRASM2 - часть AvrStudio, каковой пакет живет и здравствует.

Ну, AvrStudio - тоже не шибко популярное изделие.

>И потом - отличная подмена понятий: заброшены -> никому не нужны.

Одно является причиной другого.

>Мне лично AVRA очень даже нужен. И если разработчики на него забили, я его сам до ума доведу, ибо GPL. Потом либо перешлю разработчикам изменения, если они проснутся, либо форкну (маловероятно, поскольку программер под PC из меня - так себе).

Скорее всего вы будете самостоятельно его продолжать развивать. Все остальные уже давно взяли gas/gcc

> Неужели дурацкий "научный калькулятор" удобнее xterm -e "bc -l" (/s/xterm/gnome-terminal, konsole, etc/) навешенного на шорткат?

> Все остальные уже давно взяли gas/gcc

Господа, а вы не пробовали быть менее категоричными? :)))

>Господа, а вы не пробовали быть менее категоричными? :)))

Я вполне серьёзно. Если это не развлечение, а работа - возьми avr-gcc и работай.

> Я вполне серьёзно. Если это не развлечение, а работа - возьми avr-gcc и работай.

Возьми и работай - это не категоричность? Зачем мне что-то брать, если у меня уже есть всё необходимое? Мои потребности - лёгкий ассемблер с минимумом зависимостей, максимально совместимый со стандартным AVRASM, поскольку накоплена масса кода. AVRA подходит идеально. А что есть в AVR-GCC, чего нет в AVRA?

Я сначала подумал, что уже есть что-то, для разводки плат под linux (я знаю про eagle, но привык к PCAD-у :) ). У меня под wine в меню слоёв (Y) ничего не видно :(, но от версии к версии wine, начали появлятся хотя бы кнопки. Как у вас с этим?

А вообще, откуды такое стремление разводить платы такими кривыми дорожками? Это обусловлено технически? Просто я бы за некоторые разводки поубивал бы разводильщиков. Такую фигню разводят, что потом фиг починишь, если что не так. Извините конечно, но просто наболело. :))

> возьми avr-gcc и работай.

Не уверен, что он поддерживает tiny, или я это с avr-libc спутал...

> У меня под wine в меню слоёв (Y) ничего не видно :(, но от версии к версии wine, начали появлятся хотя бы кнопки. Как у вас с этим?

Да так же. Я выхожу из положения тем, что в начале работы создаю необходимое количество наборов слоёв (Layers -> Sets), которые определяют все требуемые мне комбинации, и переключаю видимые слои через наборы. Приемлемо.

> А вообще, откуды такое стремление разводить платы такими кривыми дорожками? Это обусловлено технически?

Вообще говоря, как раз ортогональная разводка дорожек объясняется ограниченностью трассировщиков. Идеальная дорожка та, которая идёт по кратчайшему расстоянию, огибая препятствия по дугам. Меньше длина, следовательно меньше потери. Каждая дорожка под своим углом - меньше коэффициент параллельности разводки, меньше наводок, легче получить работоспособную сверхвысокочастотную конструкцию. Плюс ко всему, TopoR эффективно минимизирует количество переходных отверстий (тоже источник ненадёжности и паразитных излучений). А зачастую разводит то, что неспособны развести другие трассировщики. Рекомендую про TopoR узнать побольше - без преувеличения, уникальный продукт. Если бы не идиотизм тамошних маркетоидов - Specctra уже тихо умерла бы.

Так что с дорожками всё в порядке. :)

> Чисто для справки - это 15.4" матрица моего ноутбука. :)

1920х1200 при 15.4" матрице это чиста канкретный бук, там дырочек для пальцев по бокам нет? :)

> Вообще говоря, как раз ортогональная разводка дорожек объясняется ограниченностью трассировщиков. Идеальная дорожка та, ...

Спасибо за разъяснения.

> Рекомендую про TopoR узнать побольше - без преувеличения, уникальный продукт. Если бы не идиотизм тамошних маркетоидов - Specctra уже тихо умерла бы.

А можно какие-нибудь ссылки? Он тоже под винду? Если да, то как он дружит с wine, какие недочёты вылезают?

> А можно какие-нибудь ссылки? Он тоже под винду? Если да, то как он дружит с wine, какие недочёты вылезают?

http://www.freestyleteam.com/ - это сайт разработчиков.

С Wine он работает удовлетворительно. Версия 3.1 правда с полпинка не запускается, но там же на сайте в форуме есть вопрос на эту тему (найти несложно), где подсказано решение - качается дополнительно пара файлов и закидывается в каталог программы.

Также во время работы выбрасывал пару пустых предупреждающих окошек - я поставил крыж "не показывать больше". На работоспособности, в той мере, в которой я это вижу, не сказалось. А что в тех окошках было - я даже не знаю. :)

Крупный недостаток - в качестве входных форматов он понимает только PDIF и ASCII PCB, каковые ни одна свободная программа не поддерживает. Так что P-CAD - это пока наше всё. Внятной информации о сроках появления поддержки других форматов я не нашёл.

Ещё один крупный недостаток (я бы сказал, фатальный) - лицензионная версия работает только под Win, ибо требует аппаратного ключа, а драйвера... ну, сами понимаете. Разработчики поддерживают желание запустить трассировщик под Wine (Lite-версия ключа не требует), но на мой вопрос о другом методе защиты - промолчали.

Там же, на сайте, весьма подробное руководство на русском в PDF (для версии 3.0). Тонкости версии 3.1 - в формате CHM.

> 920х1200 при 15.4" матрице это чиста канкретный бук, там дырочек для пальцев по бокам нет? :)

Я после своего экрана на обычные LCD-мониторы смотреть не могу - они мне мозаикой кажутся. :) А уж работать в CADах - самое оно.

А ноутбук, собственно говоря, был не так уж и дорог - я его купил за 1250 вечнозелёных (новый). Видимо по-этому отверстий под пальцы не предусмотрено. :)

> фигасе рабочих столов...

фигасе разрешение...

>> 1920х1200 при 15.4" матрице это чиста канкретный бук, там дырочек для пальцев по бокам нет? :)

>Я после своего экрана на обычные LCD-мониторы смотреть не могу - они мне мозаикой кажутся

Что за бук?

> Что за бук?

Dell Inspiron 8600C. Но он уже старый, на первом Centrino.

Что интересно - сеёчас глянул в price.ru - там всего 4 предложения, и ноут с той же конфигурацией, что и уменя при покупке, стоит тех же денег. Хотя я свой покупал полтора года назад. Истинные шедевры не дешевеют. :)

Про TopoR узнал еще тогда, когда он назывался Freestyle Router. У меня насчет этого трассировщика есть очень стойкое предубеждение, которое победить пока я не смогу, -- это непривычная эстетика печатной платы. Вот для сложных однослоек его сполне можно использовать. И некое подобие такой криволинейной трассировки имеется на гетинаксовых однослойных платах.

Насчет его преимуществ по исключению наводок -- это весьма сомнительный аргумент. Для исключения наводок в ВЧ платах все-равно используется ручная трассировка, так как изменение угла -- это недомера. Там надо думать гораздо масштабнее. Да и потом, посмотри на плотные платы, выполненные TopoR. Там видно, что параллельность трасс как была, так и осталась, но только трассы эти кривые.

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

И вопрос. А как в PCAD производится последующей редактирование криволинейных путей? Я знаю, что пути можно вести и дугами, и прямыми. Но ведь это очень трудоемко! А если подвигать что-то надо? Или отверстие под крепеж новое куда-нибудь в центр вставить, где куча путей кривых?

Я думаю, что PDIF и PCB ASCII можно попробовать преобразовать к другому формату. Они же текстовые, ЕМНИП, и описаны в документации к PCAD. В PCB (gEDA) все входные и выходные файлы текстовые, и они очень хорошо документированы. В качестве трасс там можно использовать Line, Arc, а также полигоны. Можешь в свободную минутку поисследовать теоретическую возможность интеграции путем конвертации файлов.

>Возьми и работай - это не категоричность?

Категоричность.

>Мои потребности - лёгкий ассемблер с минимумом зависимостей, максимально совместимый со стандартным AVRASM, поскольку накоплена масса кода

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

>А что есть в AVR-GCC, чего нет в AVRA?

Компилятор Си

>Не уверен, что он поддерживает tiny, или я это с avr-libc спутал...

Как какие. Те, что без ОЗУ - то только на уровне GAS/LD. Те, что с ОЗУ - и Си тоже.

> Насчет его преимуществ по исключению наводок -- это весьма сомнительный аргумент. Для исключения наводок в ВЧ платах все-равно используется ручная трассировка, так как изменение угла -- это недомера. Там надо думать гораздо масштабнее. Да и потом, посмотри на плотные платы, выполненные TopoR. Там видно, что параллельность трасс как была, так и осталась, но только трассы эти кривые.

Ручная разводка не всегда экономически выгодна. Я искренне восхищаюсь Вашим примером ручной разводки под 6 DSP, но не каждая контора может себе это позволить.

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

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

Верно. В TopoRе, насколько я знаю, пока нет средств разводки, например, дифференциальных пар. Но, с другой стороны, во-первых, два проводника без отводов от пары выводов до пары выводов TopoR и так с очень высокой вероятностью разведёт рядом, а во-вторых, у него очень развитые средства редактирования/оптимизации полученной трассировки, которые, в принципе, позволяют многие недостатки поправить вручную за считанные минуты.

> Да и закругления на поворотах ровным счетом экономии масштабной не дадут в процентном отношении от общей длины пути.

Они дадут гораздо больше - снижение излучения на углах проводников в СВЧ, когда проводник приобретает свойства волновода. А минимизация количества переходов тоже громадный плюс в этом вопросе.

> Это легко прикинуть. В два раза сократить путь -- это не всегда просто. Как правило, квалифицированный трассировщик сначала будет разбираться с узкими местами (если надо коротко, то разведет покороче), а потом все остальное будет делать.

Не могу не процитировать хрестоматийный пример (журнал EDA Expert - CHIP NEWS: "Топор для радиоинженера", апрель 2003)

---

Трассировка четырехслойной цифровой платы, обработка которой с помощью Specctra занимала два дня, с помощью программы TopoR v1.0 была выполнена за 4 часа на двух слоях (!) при втрое меньше количестве переходных отверстий и почти вдвое меньшей длине проводников.

---

Второй пример: http://www.freestyleteam.com/index.php?topic=toporbenchmark&lang=ru. 2 слоя против 8 (!), сокращение количества переходов на 45%, длины проводников на 3%.

Полагаю, вы в курсе, какую экономию даёт четырёхкратное сокращение количества слоев в серийном производстве.

> И вопрос. А как в PCAD производится последующей редактирование криволинейных путей?

Очень плохо. Плюс P-CAD не всегда понимает последовательность линий и дуг, как целый проводник. Но это компенсируется отличными средствами редактирования в самом TopoRе. Обычно я выгружаю в P-CAD уже полностью готовую оптимизированную плату (чтобы поправить, где нужно, шелкографию, и вывести в Gerber/Drill), и сохраняю проект TopoRа на случай будущих доводок.

Ещё, учитывая очень высокую скорость разводки, если нужно поменять несколько компонентов, часто оказывается, что проще и быстрее переразвести плату. Счет времени обычно идет на часы в этом случае.

> А если подвигать что-то надо? Или отверстие под крепеж новое куда-нибудь в центр вставить, где куча путей кривых?

Прямо в TopoRе раздвигаете дорожки в нужном месте, экспортируете в P-CAD и вставляете отверстие. Не скажу, что это очень легко и интуитивно делается, но сделать можно.

> Я думаю, что PDIF и PCB ASCII можно попробовать преобразовать к другому формату.

У меня опыта в программировании на PC - почти ноль. Честно говоря, мне даже в голову эта идея не приходила. Но что-то в ней есть. :) Может, займусь на досуге. Ещё бы допинать разработчиков TopoRа, чтобы они от ключей отказались - и рай на Земле наступит. :)))

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

Шли бы Вы, дяденька, с такой категоричностью детей в ВУЗе каком учить. :)

> Компилятор Си

А зачем он мне? В Tiny13 512 слов памяти, а мне в него функционала надо запихнуть немеряно, и всё должно в жёстком реальном времени работать. Плюс ко всему, наличие огромного числа собственных библиотек компенсирует мифическое падение скорости разработки по сравнению с С.

Так зачем мне переход? Ради перехода?

>У меня опыта в программировании на PC - почти ноль. Честно говоря, мне даже в голову эта идея не приходила. Но что-то в ней есть. :) Может, займусь на досуге. Ещё бы допинать разработчиков TopoRа, чтобы они от ключей отказались - и рай на Земле наступит. :)))

Захотел посмотреть примеры трассировки с указанных выше ссылок, а не вышло. Платы все в формате Accel EDA, а мне их нечем смотреть. Но зато я получил пример варианта текстового файла PCAD. И его формат просто неимоверно похож на формат PCB из gEDA. Мне кажется, что они вполне взаимопреобразуемые. Если бы пользовался Топором, то сделал бы адаптацию.

Насколько я понимаю, роль самого PCAD -- это создание футпринтов и экспорт в GERBER? То есть его функции ручного трассировщика практически смещены в сторону Топора?

>Второй пример: >http://www.freestyleteam.com/index.php?topic=toporbenchmark&lang=ru. 2 слоя против 8 (!), сокращение количества переходов на 45%, длины проводников на 3%.

Это может говорить об отстойности автотрассировщика Protel, что вполне правдоподобно. А если сравнить с автотрассоровщиком pcroute еще в PCAD 4.5, то там вообще будет тихий ужас. Там трассировщик на двухслойках затыкался. Разводил 70% быстро (на вид просто ужасно было), а на остальных 30% уходил в нирвану. Самый лучший автотрассировщик еще не написан :) Но он определенно нужен. Трассировкой должна заниматься машина. Сомнений в этом нет.

>Шли бы Вы, дяденька, с такой категоричностью детей в ВУЗе каком учить. :)

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

>А зачем он мне? В Tiny13 512 слов памяти, а мне в него функционала надо запихнуть немеряно, и всё должно в жёстком реальном времени работать.

Взять процессор побольше.

>Плюс ко всему, наличие огромного числа собственных библиотек компенсирует мифическое падение скорости разработки по сравнению с С.

А вы реально сравнивали скорость разработки на Си и на ассемблере, или вам так кажется, что набор библиотек спасёт?

Вот например, у меня вот программа на С++ не влезла в atmega64 - не буду же Я её на асме переписывать. Я просто поставлю atmega128

Вот и быдлокодеры подтянулись. Если ресурсов не хватает, мы поставим процессор помощнее, но учиться программировать не будем.

> И его формат просто неимоверно похож на формат PCB из gEDA. Мне кажется, что они вполне взаимопреобразуемые. Если бы пользовался Топором, то сделал бы адаптацию.

Начните пользоваться, он того стоит. :)

Мне кажется, проблема не только в конвертации PCB. В идеале, хотелось бы иметь возможность конвертации ещё и схем и библиотек. Причём во что-нибудь жутко универсальное, типа XML. Плюс в те же библиотеки уровень описания электрических параметров для моделирования, и 3D модели для построения трёхмерных моделей плат... Мечты.

Впрочем, начинать надо с малого. Попробую порыть описание ASCII PCB... Если найду - буду думать.

> Насколько я понимаю, роль самого PCAD -- это создание футпринтов и экспорт в GERBER? То есть его функции ручного трассировщика практически смещены в сторону Топора?

Ну, ещё в P-CADе создаются библиотеки компонентов и схемы. :)

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

> Самый лучший автотрассировщик еще не написан.

Написан. Это TopoR. :))

>Вот и быдлокодеры подтянулись. Если ресурсов не хватает, мы поставим процессор помощнее, но учиться программировать не будем.

Анонимусы-теоретики идут лесом.

> Взять процессор побольше.

Блин, не заставляйте вам грубить. Процессор - он не с потолка выбирается.

> А вы реально сравнивали скорость разработки на Си и на ассемблере, или вам так кажется, что набор библиотек спасёт?

Вот пример: контроллер станка на mega128 (был выбран только по причине существования готового отладочного модуля, требование начальства). ЖК-индикатор, клавиатура, разветвлённый интерфейс (меню, куча параметров, поддержка профилей, и т.д.), управление несколькими механизмами в реальном времени, обмен с подчинёнными агрегатами по RS-485 с арбитражом шины. Софт написан и в целом отлажен за две недели. Задействовано около 20кб ПЗУ. Это быстро или медленно?

> Вот например, у меня вот программа на С++ не влезла в atmega64 - не буду же Я её на асме переписывать. Я просто поставлю atmega128.

Вы, может, и не будете. А я просто сразу пишу на ассемблере. И мне тоже никто не мешает переехать с mega64 на mega128, которые, насколько я помню, отличаются только набором памяти. Но у меня больше шансов уложиться в 64кб памяти, и сэкономить довольно много денег на серийном производстве.

Ещё в догонку. Писать на C программы, _сопоставимые_ по скорости и компактности с ассемблерными, в принципе, можно. Особенно на AVR, у которых архитектура очень удобна для компиляторов с языков высокого уровня.

Вот только для этого нужно обладать очень нехилым знанием того, как работает компилятор, и уметь этими знаниями пользоваться. То есть, достаточно чётко представлять, как именно будет выглядеть код, полученный из той или иной конструкции С на конкретной архитектуре. А это всё равно, что писать на ассемблере - только вместо команд "rcall function" вы набираете A = function (some args).

>Вот пример: контроллер станка на mega128 (был выбран только по причине существования готового отладочного модуля, требование начальства). ЖК-индикатор, клавиатура, разветвлённый интерфейс (меню, куча параметров, поддержка профилей, и т.д.), управление несколькими механизмами в реальном времени, обмен с подчинёнными агрегатами по RS-485 с арбитражом шины. Софт написан и в целом отлажен за две недели

Не знаю. Зависит от того, насколько проработано было ТЗ, и какие алгоритмы. Но довольно быстро.

>Задействовано около 20кб ПЗУ.

А остальные 100к всё равно оттуда не выпаяешь и не продашь. Так что смысла в этом было мало.

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

Угу. 1$ на каждом устройстве.

Вообще-то, аргументов любителей ассемблера я пару лет назад начитался в RU.EMBEDDED предостаточно. Только таких любителей всё меньше и меньше остаётся. Исскуство программирования на асме - это конечно клёво. Но непроизводительно. А если завтра надо будет переписать с AVR на какой-то другой процессор? Сколько времени уйдёт на переписывание всех библиотек?

>Ещё в догонку. Писать на C программы, _сопоставимые_ по скорости и компактности с ассемблерными, в принципе, можно

Не нужно писать на Си программы сопоставимые по скорости с ассемблером. И вы это должны понимать, у вас в тексте несколько раз встречалось соловосочетание "реальное время". А в реальном времени - программа или успевает, или не успевает. Никакого быстрее/медленнее - нету.

Нехилым знанием обладать не нужно. Достаточно просто в листинг иногда поглядывать поначалу.

> А остальные 100к всё равно оттуда не выпаяешь и не продашь. Так что смысла в этом было мало.

Повторяю, это было прямое требование начальства. Я бы туда поставил Mega32.

> Угу. 1$ на каждом устройстве.

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

> Только таких любителей всё меньше и меньше остаётся. Исскуство программирования на асме - это конечно клёво. Но непроизводительно. А если завтра надо будет переписать с AVR на какой-то другой процессор? Сколько времени уйдёт на переписывание всех библиотек?

Да нисколько. В области Low end у меня только одна архитектура, и не думаю, что когда-нибудь появится вторая. От PICов я давно отказался - они у меня ничего, кроме омерзения, не вызывают. MCS-51 затрагиваю эпизодически - устарела она порядочно. 6805/6811 - экзотика в наших широтах. А на ARM, например, я на ассемблере почти не пишу, там задачи несколько другие.

>А знаете, почему китайцы впереди планеты всей? Потому, что их поделки стоят - рубль за пучок. Экономить на серийном изделии - тоже наука нелёгкая.

Их поделия стоят рубль за пучёк, потому что у них низкая зарплата. Вы хотите получать столько, сколько китайцы? Тогда пишите на асме.

Ещё у меня встречалось "жёсткое реальное время". Это когда несколько событий от внутренних блоков + два-три внешних. И у вас нет ни аппаратных блоков захвата, ни контроллеров прерываний с динамическими приоритетами. Все времянки рассчитываются _потактово_. И где можно, делается двухстадийная обработка на разных уровнях и буферирование для уменьшения времени отклика.

А не успел на один такт - потеря точности, в лучшем случае, и контроля, в худшем.

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

>Это когда несколько событий от внутренних блоков + два-три внешних. И у вас нет ни аппаратных блоков захвата, ни контроллеров прерываний с динамическими приоритетами. Все времянки рассчитываются _потактово_. И где можно, делается двухстадийная обработка на разных уровнях и буферирование для уменьшения времени отклика.

Это круто. Но почти всегда не стоит оно того времени, что на него тратится.

Да чего вы с ним спорите? Он же не привел ни одного аргумента зачем вам переходить с асма. Если человеку хочется писать на плюсах для микроконтроллеров - пусть пишет. А я перед вами снимаю шляпу, т.к. на ассемблере ныне мало кто уже умеет грамотно писать.

http://dell.merlion.ru/catalog/mobilesys/inspiron-notebooks/dell-inspiron-8600c/

Intel Pentium M 725 1.60 ГГц FSB 400 МГц / 2Мб L2 кэш
64 Мб NVIDIA GeForce FX Go5200
512 Мб PC2700 DDR SDRAM
60 GB Ultra ATA-100
Combo Drive 24x/10x/24x CD-RW + 8x DVD;
2 x USB 2.0, VGA, S-Video TV Out (7-pin mini-DIN), IEEE 1394, RJ-11 (модем), RJ-45 (локальная сеть), гнезда внешних динамиков, микрофона, Inspiron 8600 advanced port replicator
Type I или Type II PC карты
модем V.92 56K Data/Fax
Сетевой адаптер 10/100 Ethernet/LAN

высота: 38.6 мм
ширина: 361.2 мм
глубина: 276.1 мм
вес: 2.96 кг с батареей

мда, что в нём хорошего, так это разрешение, да и то непонятно как там яркость, контраст и углы обзора, всё остальное по-минимуму, вот был бы вес был около 2 кг, а так по весу практически "замена десктопа", тяжеловат под мышкой таскать :)

>Да чего вы с ним спорите? Он же не привел ни одного аргумента зачем вам переходить с асма. Если человеку хочется писать на плюсах для микроконтроллеров - пусть пишет. А я перед вами снимаю шляпу, т.к. на ассемблере ныне мало кто уже умеет грамотно писать.

Если вы не занимаетесь embedded, вы даже не понимаете, о чём спор.

Аргументы не приводятся, они уже все обсосаны на соответствующих форумах. Это примерно тоже, что сдесь спорить, что лучше - Debian или LFS.