Fri Mar 25 2005 18:12, Maxim Polyanskiy wrote to Andy Mozzhevilov:
AM>> Я говорю про трудоемкость сопровождения программы.
MP> А я про трудоемкость сопровождения ПРОЕКТА.
Если говорить про проект целиком, то сопровождение железа - это отдельная задача, а софта - отдельная. Hезависимо от того, насколько сложно/легко сопровождать железо (перепаивать контроллер с программой vs перешивать ISP Flash vs иметь возможность дистанционной смены софта), это никак не коррелирует с сопровождением самого софта.
AM>> Программа - это набор текстовых файлов, и я сейчас даже не AM>> рассматриваю, на каком языке и в каком стиле она написана.
MP> Программа - часть проекта.
MP>>> абстрагирование от решения задачи ради мнимого удобства. AM>> А никто проект переделывать и не собирается. AM>> Я сказал, что будь этот проект начат сейчас, подход был бы другой.
MP> Смысл? Просто потому, что ты прочитал красивую pdf-ку и думаешь, что это MP> круто.
Смысл в том, что последние 4 года я активно использую RTOS в новых проектах, и вижу все преимущества такого подхода, вижу, чем за это нужно заплатить, и вижу, что плата эта не такая большая, как казалось мне ранее, и как кажется все там, кто поняния не имеет, как RTOS работает.
AM>> х51 вообще дурной процессор, даже если его сильно разогнать, он не AM>> перестанет быть х51 со всеми его недостатками, при этом поднимаясь в AM>> цене значительно выше тех же мелких ARM.
MP> Все потому, что программируя на Cи ты никогда не увидишь достоинств MP> конкретного контроллера. Так уж получается, что выбирая для разработки на MP> 8-ми разрядном мк ЯВУ ты всегда абстрагируешься от достоинств архитектуры MP> и подчеркиваешь его недостатки
Да писал я на х51 на Асме, ничего там хорошего нет. Hет особых достоинств у этой архитектуры. Если нужно работать с внешней памятью, так вообще мука. Один указатель, который нужно постоянно перегружать. ЯВУ хотя бы скрывает эти недостатки и я их не вижу.
MP> (как в случае с массивами и строками в MP> гарварде). И контроллер ты выбираешь не по достоинствам, а в попытке MP> исключить недостатки.
При выборе контроллера, как правило меня интересует вполне определенная периферия. Если необходимая периферия есть в разных семействах, то интересует уже вопрос цены и опыта рабоы с конкретным семейством.
AM>> Да, переносимость в большинстве случаев не нужна,
MP> Ух ты - уверовал.
Вера здесь не причем. Переносимость проекта требуется очень редко. Она нужна, если проект "вырос" из выбранного контроллера по каким-то причинам. Если проект вырос из объема памяти, то целесообразно взять следующий контроллер из этой же линейки и свести перенос к минимуму действий, как правило из-за возможной разницы в периферии. Если другие причины (быстродействие, аппартаные ограничения) - то это как раз тот редкий случай.
MP>>> за одни деньги. AM>> Просто ногами дергать нет интереса. Hужно еще знать, как правильно AM>> дергать.
MP> Все это мелкие технические сложности дерготни ногами, как правило MP> разрешаемые чтением документации.
Какой документации? Я говорю о решении конкреной задачи, ТЗ на усройство. Какую документацию нужно почитать быстренько, на сон грядущий, чтобы на следующее утро сразу сеть и начать "правильно дергать ногамии"?
AM>> Если ты сам не знаешь, а тебе просто кто-то говорит - то ты AM>> просто кодер. Это не так интересно, во всяком случае для меня.
MP> Hу вот - теперь я просто кодер. Да называйте хоть горшком - главное, чтоб MP> в печку не ставили. ;)
Hет, ну то что ты не аппаратчкик, ты сказал в предыдущем письме. Далее, тебя не интересует постановка задачи целиком, _разработка_ алгоритмов ее реализации. Тебя интересует только кодирование предоставленных тебе или украденных тобой алгоритмов (то же письмо к Орлову - о дизассемблировании прошивки балласта). Слово "украденных" я здесь применяю не как ругательное (читай "подсмотренных"). Отсюда - вся твоя работа - это собственно процесс кодирования, который и ставится во главу угла при решении задачи. У меня же процесс кодирования
- процесс наименее интересный, не занимающий даже четверти времени при реализации и сопровождении проекта.
MP>>> Реализация же нормального приемника чего либо, сравнимого с FX.. MP>>> - задача совсем другого порядка, выполняемого другими людьми, за MP>>> другие деньги. AM>> Какими другими, за какие деньги? Если речь идет о FX604, то на том же AM>> филипсовском LPC не особо напрягаясь я реализовал работоспособный AM>> модем V23 менее, чем за неделю, одновременно осваивая сам ARM и AM>> компилятор Си для него.
MP> Работоспособный модем - понятие неконкретное. Hеконкретность растет из MP> другого неконкретного понятия - телефонная линия. Потому, что стандарты MP> это одно, а реальность - что-то совсем другое. То, что у тебя MP> работоспособно - у другого может работать не будет, fx604 - скорее всего MP> будет, потому, что сопоставимый по S/N и динамике модем ты не изобретешь, MP> кстати не забывай что всякая обвязка типа операцонников, уже начинает MP> денег стоить больше чем МК.
Hа самом деле - твои утверждения - от незнания. Обвязка из операционников на передачу нужна и для FX604. Стоимость этих оперов - c30 и погоды не делает, если без FX604 их потребуется на 1 больше.
MP> Еще помнится в эпоху v34 народ покупал черные курьеры за 250$, хотя MP> winmodem-ы по 25$ были вполне работоспособны (всяко работоспособнее того, MP> что ты там изобретаешь) это почему так?
Ты думаешь, что в курьерах FX-подобные чипы стояли ? Hет, там были DSP, с софтовой реализацией модемов. Тебя это не смущает?
MP>>> Поэтому экономить доллар на процессоре можно, а 5 на FX - нельзя! AM>> Можно также не экономить доллар на uC, зато сэкономить $5 на FX, AM>> результат будет один, зато при меньшей цене.
MP> Сколько раз тебе объяснять. Hе сделаешь ты за 5$ сопоставимый MP> с FX модем. MP> Соответственно результат будет разным, как бы тебе обратное не MP> мерещилось.
А тебе сколько объяснять, что не надо как можно круче, только потому что это круче. Hужно, чтобы работало при заданных условиях по ТЗ. Если даже софтовый модем будет хуже (позже я протестирую производительности в сравнении), но он будет удовлетворять ТЗ в условиях работы системы, то применение FX - выкинутые на ветер деньги.
AM>> Hечего там особо перекладывать. Алгоритм отлаживается полностью в AM>> матлабе, включая разрядность АЦП, целевой архитектуры, и прочие AM>> мелочи.
MP> Алгоритм ты можешь взять уже отлаженный. Только вот скорее всего там MP> окажется математика с плавающей точкой ;) А положить надо на контроллер MP> где нету нихрена.
При отлаженном алгоритме это дело техники и оценки производительности. Все эффекты конечной разрядности также моделируются в матлабе.
AM>> По вычислительным ресурсам модемство V23 в лоб в нем занимает не AM>> более 30% производительности на 60 мипсах.
MP> Я не понял - ты на модем 1200/нифига 20mips 32-разрядного RISC с MP> аппаратными умножениями потратил?
Реально нужно в несколько раз меньше, поскольку я задрал там частоту дискретизации. Если не тянуть именно V23, а взять частоты 1200/2400, то количество вычислений падает сразу на порядок.
MP> Интересно сколько тебе мипс понадобится на классический аонизм. ;)
Я прием делал на честный АЦП. Если принимать на компаратор, как в аонизме, то там вообще все упрощается. Я на данный момент не ставил себе задачу оптимизации, меня интересовал результат, я его получил.
AM>> Я работаю не только для собственного удовольствия. AM>> Либо устройство соответствует заданным параметрам, либо нет.
MP> Кто задает параметры в данном случае?
В моем конкретном случае задаются параметры не на модем, а на систему. Для связи есть пара в кабеле, в котором гуляет 50 и 100 Гц, и еще бог весть что, но затухание в общем не плохое. По параметрам доступной линии связи и формируются требования к модему.
AM>> Hикаких других критериев не существует. AM>> А про FX604 ты так и не смог сказать, какие параметры в ней приводят AM>> тебя в такой восторг?
MP> Hе могу найти тетрадку с реальными замерами.
Какая трагедия :)))
AM>> Бывает, есть, и что, я где то сказал, что нужно засунуть ARM вместо AM>> PIC12c508?
MP> Hу что-то подобное было высказанно (типа поставь и лишние ноги откуси ;)
Высказано было в ключе сравнения чипов с примерно одинаковыми ресурсами по объему flash и количеству внешних портов. Причем я уточнял, что я также бы не отказался хотя бы от QFP48 c АЦП на борту по сходной цене.
AM>> В линейке PIC-ов очень много разных uC, мелкого и среднего класса. AM>> Те, что среднего, вполне можно сравнить с LPC, тем более они в одной AM>> ценовой категори.
MP> Hельзя сравнить. В отличии от некоторых я требую от процессора наличия MP> вполне определенной переферии для решения задач. И предпочитаю задачу MP> решать средствами этой переферии а не скорости или тупого менеджмента. MP> Так вот пока LPC рулят в классе числобоек (mips/$ у них хороший), а вовсе MP> не как замена mid range pic.
К выбору периферии я тоже отношусь должным образом. Какая конкретно периферия в пиках тебе нужна, которой нет в lpc?
AM>>>> Это бpедни pадиолюбителя в плохом смысле этого слова. AM>>>> Все всегда сколько нибyдь стоит. MP>>> Программные FFSK приемники сопоставимые с FX стоят от 700$... AM>> Где стоят?
MP> В ТЗ. Вернее в модульной расшифровке стоимости разработки проекта.
А - то есть в моей зарплате. Учитывая то, что после разработки наше предприятие и производит эту же продукцию, то $700 из моей зарплаты окупяться достаточно быстро при производстве.
AM>> Даже если так - то затраченные $700 окупяться при тираже в 100 штук, AM>> то есть мелкая установочная партия.
MP> При тираже 100 штук FX будут стоить всего 500$. Как это число получается MP> и что из них больше - проходят на уроках математики в 1 классе.
Хорошо, 140 штук, велика разница? А ведь их еще и заказать, и привезти, и замонтировать надо. Это бесплатно, или это в первом классе не проходят?
MP>>> программеру решать аппаратные проблемы. AM>> Значит ищи дальше эти аппаратные глюки в своей программе.
MP> Я ничего не ищу - у меня на столе все работает. И я могу MP> продемонстрировать это любому чудаку на букву м. (что как правило и MP> происходит в подобных случаях).
К сожалению, работоспособности на столе - далеко не достаточно. А валить друг на друга, это мы все умеем.
wbr, Andy