Форум разработчиков электроники ELECTRONIX.ru

SpiritDance

Jul 13 2006, 12:13

Цитата(CD_Eater @ Jul 13 2006, 15:04)

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

Так вобщем для этого и нужно ТЗ за подписью заказчика, чтоб ВСЕ представляли себе объем работ. При таком документе пусть хоть как смотрит - до лампочки.

Harbinger

Jul 13 2006, 17:37

Цитата(SpiritDance @ Jul 13 2006, 13:38)

ведь с точки зрения заказчика всё просто: "Добавь-ка мне вот такую мелочь в программу"

Если бы добавить. Частенько просят выбросить то, что в ТЗ не прописывалось, а получилось как побочная (и вредная!) фича. К примеру, каково, когда к Вам самостийно дозванивается автоответчик и предлагает записать сообщение?

_Bill

Jul 14 2006, 11:12

Цитата(SpiritDance @ Jul 13 2006, 15:13)

Цитата(CD_Eater @ Jul 13 2006, 15:04)

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

Так вобщем для этого и нужно ТЗ за подписью заказчика, чтоб ВСЕ представляли себе объем работ. При таком документе пусть хоть как смотрит - до лампочки.

А еще лучше составить ТЗ совместно с Заказчиком. Тогда проблем с ним будет меньше
"Бумаги, которые мы пишем"

pokos

Jul 14 2006, 11:29

Цитата(_Bill @ Jul 14 2006, 15:12)

А еще лучше составить ТЗ совместно с Заказчиком.

Что значит "лучше"????

ТЗ только так и составляется.

_Bill

Jul 14 2006, 11:34

Цитата(pokos @ Jul 14 2006, 14:29)

Цитата(_Bill @ Jul 14 2006, 15:12)

А еще лучше составить ТЗ совместно с Заказчиком.

Что значит "лучше"????

ТЗ только так и составляется.

Да, всяко бывает. Если по уму, то нужно обязательно с Заказчиком.

SasaVitebsk

Jul 15 2006, 18:55

Цитата(CD_Eater @ Jul 13 2006, 13:00)

О, да ! Этого у Атмел не отнять. Сам испытываю подобные проблемы - старые чипы исчезают, а перелопачивать программу под новые - удовольствие небольшое. Здесь Атмел не рулит. Хотя их можно понять - каждый раз, желая сделать новые чипы лучше, хочется разрушить всё старое, а на его месте создать шедевр, правда, который тоже будет недолговечен. А совместимость с предыдущими чипами - это, увы, обуза для инноваций. Наблюдаю подобное в своей практике (моя основная работа - программирование для PC) - каждый год переписываю в общем-то немаленький проект (более 30 тыс.строк кода) почти с нуля, ломая почти всю логику работы программы, дабы сделать её ещё лучше, хотя требуется лишь добавить новую функциональность, правда, не предусмотренную при изначальной постановке задачи. Увы, пожелания заказчика непредсказуемы, но выполнять их надо. А переписываю с нуля для того, чтобы сделать программу как можно более универсальной относительно предполагаемых будущих "сюрпризов" со стороны заказчика. Молюсь, чтобы его очередное "пожелание" не пошло вразрез с хардварной частью (парой сотен устройств на МК, с которыми общается компьютер), до сих пор всё обходилось изготовлением дополнительных устройств (в отдельных корпусах) и подключением их к контактам в/в общего назначения старых устройств - получаются такие "навесные" апгрейды (вам, наверное, смешно...). Когда вспоминаю, что сначала хотел сделать первоначальные устройства вообще без возможностей расширения (ведь изначально ничто не предполагало такой изменчивости пожеланий заказчика), меня пробирает лёгкий холодок ужаса. Вероятно, у многих из вас ситуация другая - разработал, изготовил, продал (или запустил серию) и отдыхаешь, поэтому проблема обслуживания не знакома. Те же, кто делает изделия под одного конкретного заказчика, меня поймут - желание "разрушить всё старое и создать с нуля" постоянно приходит в противоречие с необходимостью "плавного безболезненного (недорогого) апгрейда", ведь с точки зрения заказчика всё просто: "Добавь-ка мне вот такую мелочь в программу"

Справедливости ради следует сказать, что в лидеры по популярности среди 8-битных МК AVR вышел благодаря тому, что Атмел не стал придерживаться старых привычных традиций, а создал своё ядро, абсолютно новое и лучше предшественников. Другие конторы предпочитают не рисковать и делают клоны 51-х МК. Этот смелый шаг Атмела окупился. Так что иногда необходимо "разрушить всё старое".

Теперь немного понятно.

Кстати у нас всё не так безоблачно. Представте себе что одно из изделий пошло в серию. Постепенно внесли некоторые изменения как в программу (ну скажем штук 30 принципиальных) так и в схему/плату (ну скажем штук 10).

Ну а порты соединяются, как известно, как дорожки на плату легли.

И вот потом всё это поддерживать приходится. А сразу, конечно, этот момент непродумал. Ну и пошло - поехало. А изделий то много. Короче хорошо там, где нас нет. Нас - это всмысле программистов/схемотехников.

Вон сколько стиральную доску не модернизировали.

Насчёт нового ядра - Atmel конечно молоток. А вот насчёт развития этого ядра, я придерживаюсь мнения уже кем-то здесь высказанного. Они сами не ожидали такого комерческого успеха. И, поэтому, у них изначально небыло чёткой стратегии развития данного ядра. А нарекания были. Потребность росла. Я помню на раннем этапе им впрямую задавали вопрос по развитию переферии и росту тактовой частоты. И Atmel прямо отвечал, тактовая частота подниматься не будет, семейство развиваться не будет! Кстати они видно настолько не были уверены в успехе, что первые камни сделали совместимыми по ногам с тем же 8051 (4414,8515), со своей 2051(1200,2310) и с пиками. Вот отсюда и длительный процесс становления кристаллов на рынок и отработка их прямо у потребителя. Кстати писали они и о том что разрабатывается контроллер уровней прерывания. Жду не дождусь его. Он нужен практически в каждом проекте. А они всё тянут.

CD_Eater

Jul 15 2006, 21:46

Цитата

Кстати они видно настолько не были уверены в успехе, что первые камни сделали совместимыми по ногам с тем же 8051 (4414,8515), со своей 2051(1200,2310) и с пиками.

Совместимость по ногам - возможность переманить разработчиков уже выпускающихся проектов, облегчив им переход на новые чипы. Многие производители м/схем так делают. Неуверенность в успехе здесь ни при чём

Цитата

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

Может и правильно, что глобальных изменений не предвидится. Всё-таки соблюдать совместимость с младшими моделями - это обуза, тянущая назад, не дающая обогнать конкурентные модели, собранные с нуля. Вспомните 8086 и его трансформацию в 80386 - фактически получился новый процессор, но для совместимости сбоку присобачен эмулятор старого 8086. Неэлегантно и неэффективно. У совместимости кроме минуса (необходимости поддерживать хардварную преемственность) есть свой плюс - почти бесплатная переносимость программ (особенно если софта очень много, как в PC), и применительно к интеловским процессорам этот плюс перевешивает. А вот для МК - нет, поскольку совместимость по программам выражена не так сильно (по этому поводу здесь уже высказывались, жаловались на потерянное здоровье при переносе программ между разными AVR-ками

). А периферия для 8-битника у AVR-ок и так чуть ли не самая лучшая.

Цитата

Кстати писали они и о том что разрабатывается контроллер уровней прерывания. Жду не дождусь его. Он нужен практически в каждом проекте. А они всё тянут

То, что вы хотите (изменение логики обработки прерываний, включая возможность автоматического временного запрета обработки прерываний с уровнями ниже обрабатываемого в текущий момент), затрагивает основы ядра. Мне кажется, вряд ли это будет реализовано в 8-битных AVR-ках. ИМХО. За последние несколько лет периферия постоянно менялась, а ядро - нет. Хотя формально ядра чуть отличались, но фактически из ранних моделей просто вырезались неиспользуемые куски, например, умножитель или интерфейс внешнего ОЗУ, хотя изначально ядро разрабатывалось таким, чтобы предусмотреть возможность использования этих кусков, когда они будут нужны. Поэтому, например, ограничение на 64Кбайт ОЗУ и неполноценность контроллера прерываний - это "фичи", которые будут наследоваться всеми AVR-ками.

proba

Jul 16 2006, 16:53

Цитата

Может, Вам ещё вложенные стековые кадры с инструкциями enter/leave хочется в 8-битном МК ?

Есть и такое, например у всей линейки МК от Fujitsu, начиная с 8-ми битников.

Не проверял, но сомневаюсь, что в МК засунут инструкцию, выполняющуюся сотни тактов.
Для справки: у интеловской x86 инструкции enter есть параметр level, который может изменяться от 0 до 31. Именно об этой вложенности я и говорю. А Вы, вероятно, только про случай level=0. Если ошибаюсь - поправьте.

Может быть о разном говорим хотя названия похожи, асма на x86 под рукой нет. Для справки по МК от Fujitsu:
ENTER #N - Function entry processing (где N - объем резервируемой памяти)
LEAVE - Function exit processing
Первая резервирует память в стеке для локальных переменных, вторая освобождает. При этом определенный регистр получает значение адреса начала локальных переменных в стеке, через этот регистр выполняются все операции с локальными переменными.

аналогично с командами ENTER # и EXIT работает и M16C от Renesas.
отсутствие вожможности записи несколких регистров , xоть пар одновременно , один из самых больших недостатков AVR, доля PUSH-POP команд в листинге слишком болшая.

dxp Jun 26 2006, 08:55

Цитата

Из простых тестов могу привести следующее. Вернее, это не тест в самом деле, а просто сравнение эффективности одного и того же куска кода из аналогичных проектов. Там в том и другом было вычисление полинома (от двух переменных) вида:

Цитата

float math::Pxy(__flash PxyCOEFFS a, const float x, const float y)
{
float X_2 = x*x;
float Y_2 = y*y;

return a[9]*X_2*x + a[8]*Y_2*y +
a[7]*X_2*y + a[6]*x*Y_2 +
a[5]*X_2 + a[4]*Y_2 +
a[3]*x*y + a[2]*x + a[1]*y + a[0];
}

Результат:
MSP430F149 : 5197 тактов
ATmega163 : 11941 такт

странно, я и на M16C, ядро которого imho еффективнее MSP430 получаю около 7200 тактов. могли ли Вы дать исходные значения Вашего теста ?.

_Bill

Jul 17 2006, 11:03

Цитата(dxp @ Jun 26 2006, 08:55)

Из простых тестов могу привести следующее. Вернее, это не тест в самом деле, а просто сравнение эффективности одного и того же куска кода из аналогичных проектов. Там в том и другом было вычисление полинома (от двух переменных) вида:

Код

float math::Pxy(__flash PxyCOEFFS a, const float x, const float y)
{
    float X_2 = x*x;
    float Y_2 = y*y;

    return a[9]*X_2*x + a[8]*Y_2*y +
           a[7]*X_2*y + a[6]*x*Y_2 +
           a[5]*X_2   + a[4]*Y_2   +
           a[3]*x*y   + a[2]*x     + a[1]*y + a[0];
}

Результат:
MSP430F149 : 5197 тактов
ATmega163 : 11941 такт

Данный пример характеризует принцип "Сила есть - ума не надо". Использование для вычисления полинома схемы Горнера гораздо эффективнее данного кода. И как знать, разница в тактах между MSP и AVR в этом случае возможно будет меньше.

dxp

Jul 25 2006, 04:07

Цитата(_Bill @ Jul 17 2006, 18:03)

Цитата(dxp @ Jun 26 2006, 08:55)

Из простых тестов могу привести следующее. Вернее, это не тест в самом деле, а просто сравнение эффективности одного и того же куска кода из аналогичных проектов. Там в том и другом было вычисление полинома (от двух переменных) вида:

Код

float math::Pxy(__flash PxyCOEFFS a, const float x, const float y)
{
    float X_2 = x*x;
    float Y_2 = y*y;

    return a[9]*X_2*x + a[8]*Y_2*y +
           a[7]*X_2*y + a[6]*x*Y_2 +
           a[5]*X_2   + a[4]*Y_2   +
           a[3]*x*y   + a[2]*x     + a[1]*y + a[0];
}

Результат:
MSP430F149 : 5197 тактов
ATmega163 : 11941 такт

Данный пример характеризует принцип "Сила есть - ума не надо". Использование для вычисления полинома схемы Горнера гораздо эффективнее данного кода. И как знать, разница в тактах между MSP и AVR в этом случае возможно будет меньше.

Вы имеете в виду преобразование полинома вида

An*x^n + An-1*x^n-1 + An-1*x^n-2 + ... + A0

к виду

(...((An*x + An-1)*x + An-2)*x + ...)*x + A0 ?

Естественно, этот вариант быстрее, т.к. тут меньше умножений. Но мне со свистом хватало даже производительности AVR (нужно было вычислять результат с чатотой 10 Гц). Т.ч. данный пример характеризует принцип "Не нужно заниматься оптимизациями там, где это не требуется".

Что касается разницы в тактах между MSP430 и AVR, то, разумеется она будет меньше, т.к. и само количество тактов будет меньше, но соотношение производительности сохранится на примерно том же уровне.

Кстати, не покажете, как разложить вышеотквоченный полином двух переменных по Горнеру?

_Bill

Jul 25 2006, 08:31

Цитата(dxp @ Jul 25 2006, 07:07)

Естественно, этот вариант быстрее, т.к. тут меньше умножений. Но мне со свистом хватало даже производительности AVR (нужно было вычислять результат с чатотой 10 Гц). Т.ч. данный пример характеризует принцип "Не нужно заниматься оптимизациями там, где это не требуется".

Что касается разницы в тактах между MSP430 и AVR, то, разумеется она будет меньше, т.к. и само количество тактов будет меньше, но соотношение производительности сохранится на примерно том же уровне.

Кстати, не покажете, как разложить вышеотквоченный полином двух переменных по Горнеру?

Согласен, я тоже не особенно стараюсь оптимизировать, когда этого не требуется. Но, в силу привычки и заранее зная особенности компилятора, пишу так, тобы код получался по возможности оптимальным. Правда, в таких случаях приоритет отдается наглядности и простоте программы. Если же требуется оптимизация программы, то наглядность и простота уходят на второй план.
Что касается данного примера полинома, то по Гореру его можно написать примерно так:

Код

z = ((a[9]*x + a[5])*x + a[2)*x + ((a[8]*y + a[4])*Y) + a[1])*y + (a[7]*x + a[6]*y + a[3])*x*y + a[0];

SasaVitebsk

Jul 25 2006, 18:02

Цитата(_Bill @ Jul 17 2006, 14:03)

Цитата(dxp @ Jun 26 2006, 08:55)

Из простых тестов могу привести следующее. Вернее, это не тест в самом деле, а просто сравнение эффективности одного и того же куска кода из аналогичных проектов. Там в том и другом было вычисление полинома (от двух переменных) вида:

Код

float math::Pxy(__flash PxyCOEFFS a, const float x, const float y)
{
    float X_2 = x*x;
    float Y_2 = y*y;

    return a[9]*X_2*x + a[8]*Y_2*y +
           a[7]*X_2*y + a[6]*x*Y_2 +
           a[5]*X_2   + a[4]*Y_2   +
           a[3]*x*y   + a[2]*x     + a[1]*y + a[0];
}

Результат:
MSP430F149 : 5197 тактов
ATmega163 : 11941 такт

Данный пример характеризует принцип "Сила есть - ума не надо". Использование для вычисления полинома схемы Горнера гораздо эффективнее данного кода. И как знать, разница в тактах между MSP и AVR в этом случае возможно будет меньше.

Давайте взглянем на это по другому 5197т MSP на 8MHz = 650 mks
11941t AVR на 16MHz = 746mks
Проигрыш 13%

Но, я ещё раз отмечаю, данное ядро не предназначено для мощной арифметики. Это скорее плюс к остальным его достоинствам. А это фоновые задачи, которые на слишком вылизаны по времени.

Одно замечание по поводу контроллера прерываний. В 8080, 8086 он был отдельным устройством и я смотрел его работу. И смею утверждать, что сие устройство можно реализовать не затрагивая ядра МП.

CD_Eater

Jul 25 2006, 18:30

МК есть куча разных устройств, собранных вместе в одном чипе

А в 8086 всё было по-отдельности: проц, память, контроллер памяти, контроллер ДМА, контроллер прерываний, контроллер периферийных устройств (таймер + динамик), контроллер посл. порта, контроллер параллельного порта, микруха с БИОС наконец. А сейчас почти всё в одном чипе МК (то есть, почти вся мат.плата (от IBM PC XT) вместе с 8086, только без шины ISA и контроллеров клавы, FDD, HDD).

Хотя, реализовать-то, наверное, можно...

P.S. Забыл, что контроллеры портов, FDD, HDD были на отдельных мультикартах, а не на материнке. Но сути это не меняет

zltigo

Jul 25 2006, 18:51

Цитата(SasaVitebsk @ Jul 25 2006, 21:02)

Одно замечание по поводу контроллера прерываний. В 8080, 8086 он был отдельным устройством и я смотрел его работу. И смею утверждать, что сие устройство можно реализовать не затрагивая ядра МП.

Посмотрите тогда еще раз. В процессе рассмотрения попробуйте ответить на вопросы:
1. Что это такое за два сигнальчика INT и INTA и к чему они "подключаются" и к чему их
"подключить" в непредназначенном для этого CPU?
2. А кто это позволяет вышеупомянутым контроллерам получить доступ к шине и покомандовать куда
процессору идти?

_Bill

Jul 25 2006, 19:47

Цитата(zltigo @ Jul 25 2006, 21:51)

Цитата(SasaVitebsk @ Jul 25 2006, 21:02)

Одно замечание по поводу контроллера прерываний. В 8080, 8086 он был отдельным устройством и я смотрел его работу. И смею утверждать, что сие устройство можно реализовать не затрагивая ядра МП.

Посмотрите тогда еще раз. В процессе рассмотрения попробуйте ответить на вопросы:
1. Что это такое за два сигнальчика INT и INTA и к чему они "подключаются" и к чему их
"подключить" в непредназначенном для этого CPU?
2. А кто это позволяет вышеупомянутым контроллерам получить доступ к шине и покомандовать куда
процессору идти?

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

Kopa

Aug 16 2006, 08:05

Цитата(Harbour @ Jun 20 2006, 08:25)

Сильно на C разгонишься когда памяти 512 байт.

Может тогда кто-нибудь подскажет как на С программировать 12-е PIC-и

А то все их только с асмом используют.

µµC

Aug 16 2006, 16:07

Цитата(Kopa @ Aug 16 2006, 12:05)

Может тогда кто-нибудь подскажет как на С программировать 12-е PIC-и

А то все их только с асмом используют.

А что, есть какие-нибудь проблемы? PIC12 до 2 килослов флеша и до 128 байт ram. ИМХО, если не учитывать пионеров (и редкие форс-мажорные случаи), _все_ остальные пишут на С и для PIC12 и для PIC10. Ибо нефиг вручную банки переключать.