Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: AVR признали !
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > AVR
Страницы: 1, 2, 3, 4, 5, 6
zltigo
Цитата(Прохожий @ Aug 10 2007, 01:28) *
А посмотреть, чего там в реальности напринималось в буфер? Или что творится с АЦП?

Понимаете, что "напринималось в буфер" это настолько мелкая проблема на фоне остальных, что она будет решаться средствами отладки ориентированными на все остальное. В моем случаее это обязательная отладочная консоль. Причем консоль, это отдельная задача с определенным проиритетом и сепень ее загружености не приводит к существенным временным перекосам основного алгоритма. Память под буфера выделяется через менеджер памяти, что позволяет всегда у него спросить информацию о блоках памяти и их владельцах не разбираясь с конкретным мапфайлом. Зачастую буфера не абстрактны а обслуживаются, например, системным механизмом очередей, что в свою очередь позволяет запросить интимную информацию и у менеджера очереди. Ну а дальше - запросить дамп памяти в которой находится буфер и все.
Зачем мне в описанной реальной системе для посмотреть "напринималось в буфер" внутриcхемный отладчик smile.gif?. На самом деле, я "сырые" буфера и не смотрю в принципе - когда более высокие уровни будут разбираться с тем, что "напринималось", у них и попрошу уже форматированную распечатку.
rx3apf
Цитата(pokos @ Aug 10 2007, 11:18) *
Ну, не хочу развивать религиозного фанатизьма, однако, в моём списке PIC отсутсвует.
Присутствуют COP, 48, 51, AVR. Когда-то передо мной стоял выбор между PIC и AVR, решён был в сторону AVR, поскольку в то время за сравнимые деньги можно было купить AVR с FLASH, а PIC только OTP, такой же кристалл PIC с FLASH был на порядок дороже.


Когда же это было ? Первые, 90s2313, стоили примерно столько же, сколько первые флешаки от Microchip (16F84), порядка зеленой пятерки в то время. 90s8515 - около восьми баксов. О каком порядке разницы может идти речь ? Конец 90-х...
zltigo
Цитата(_artem_ @ Aug 10 2007, 03:28) *
А для чего организовывать пересылки массивов в мтп2?

Заметьте, слово "массивов" добавили Вы. Я говорил просто пересылки. Теперь об MTP2
1. Крути не крути информацию из буферов HDLC контроллера переслать в большой буфер хранящий принятые пакеты надо.
2. Далее 'указатели' на сообщения в этом буфере попадают в разные очереди сообщений
это тоже пересылки, хоть и не массивов, но уже заметных обьемов информации порядка десятков байт
(для 32bit ARM, говорю)
3. Передаваемые сообщения тоже идут в буфера, один из которых достаточно велик, поскольку у нас имеют право потребовать перепослать до 128 последних информационных сообщений. Соответственно 128 'указателей' на эти сообщения посылаются в кольцевую очередь из которой они при необходимости извлекаются и перекладываются в очередь к процессу передачи.
4. Достаточно?
Все это пересылки. Пересылки не тел сообщений (что являлось-бы явно неправильно спроектированным алгоритмом), но тем не менее пересылки память-память.
Andreas1
Цитата(zltigo @ Aug 10 2007, 11:11) *
Зачем мне в описанной реальной системе для посмотреть "напринималось в буфер" внутриcхемный отладчик smile.gif?. На самом деле, я "сырые" буфера и не смотрю в принципе - когда более высокие уровни будут разбираться с тем, что "напринималось", у них и попрошу уже форматированную распечатку.

Напоминает спор о курице и яйцах smile.gif
А отлаживать "более высокие уровни " с отладчиком быстрее и удобнее. Тогда и заглянуть в буфера понадобится.
Цитата
Когда же это было ? Первые, 90s2313, стоили примерно столько же, сколько первые флешаки от Microchip (16F84), порядка зеленой пятерки в то время.

Использовал 90s2313 с самого начала как замену 16f84. Не более $2,5 против $4 в тех-же количествах и разница быстро нарастала.
pokos
Цитата(rx3apf @ Aug 10 2007, 12:29) *
Когда же это было ? Первые, 90s2313, ...

Ну, до него был ещё 90s1200. Кстати, 16-й серии PIC тогда ещё не было.
В то время "флешаки" от PIC считались отладочными кристаллами с соответсвующей ценой. Это уже потом Мицрочип рюхнулся, что Атмел рынок отбирает, и цены пошли вниз.
У Атмела ведь в то время был уже целый выводок флешных 51-х контроллеров. Меня особо радовал в них узкий DIP-корпус...
rx3apf
Цитата(Andreas1 @ Aug 10 2007, 12:43) *
Использовал 90s2313 с самого начала как замену 16f84. Не более $2,5 против $4 в тех-же количествах и разница быстро нарастала.

Да, пожалуй, эти цифры ближе. 1200 стоил около двух, 2313 чуть дороже, 16f84 успели чуть подешеветь. но 8515 точно стоил около восьми в розницу. Примерно столько же, сколько и появившийся чуть позже pic16F876/877. В любом случае, о разнице в стоимости на порядок речи не идет.


Цитата(pokos @ Aug 10 2007, 12:50) *
Ну, до него был ещё 90s1200.

2313 реально появился в продаже раньше (ну, с поправкой на продавцов - можно считать, что одновременно). Анонсирована была куча камней, которые так и вообще не появились...
Цитата(pokos @ Aug 10 2007, 12:50) *
В то время "флешаки" от PIC считались отладочными кристаллами с соответсвующей ценой.

А вот этого никогда не было. На момент появления первых AVR единственным флешевым кристаллом у Microchip был 16C84 (ну и F84 в этот момент появился). Отладочными кристаллами, с "соответствующей ценой" были керамические, UV-стираемые ($10 и выше), с порядка сотней заявляемых циклов перезаписи. И жутко дорогие кристаллы для внутрисхемных эмуляторов. В 98-м были анонсированы (а в 99-м появились) 16F87x.
Цитата(pokos @ Aug 10 2007, 12:50) *
Это уже потом Мицрочип рюхнулся, что Атмел рынок отбирает, и цены пошли вниз.
У Атмела ведь в то время был уже целый выводок флешных 51-х контроллеров. Меня особо радовал в них узкий DIP-корпус...

А я как их купил (в том числе и первых 40-ногих) - уж больно цена понравилась, так ни разу и не попробовал wink.gif Попробовав RISC, на CISC уже обратно не тянет совершенно. И как я раньше любил Z80 ?
zltigo
Цитата(Andreas1 @ Aug 10 2007, 11:43) *
Напоминает спор о курице и яйцах smile.gif

Отнюдь sad.gif, напоминает попытку разговаривать о вкусе продукта, который один из собеседников не пробовал.
Цитата
А отлаживать "более высокие уровни " с отладчиком быстрее и удобнее.

Простите, отвечу коротко - нет. Понятие 'высокого', конечно у всех разные, но одну обыденную относительно простую задачу я называл в предыдущих постах. Можете попробовать ознакомиться и подумать на досуге, куда там внутрисхемную отладку по шагам с просмотром регистров (ну или буферов) притянуь. Можете подумать и чем-нибудь более простом, массовом и понятном, например о пользе внутрисхемного отладчика для отладки стека IP протоколов.
pokos
Цитата(rx3apf @ Aug 10 2007, 13:00) *
... На момент появления первых AVR единственным флешевым кристаллом у Microchip был 16C84 (ну и F84 в этот момент появился). Отладочными кристаллами, с "соответствующей ценой" были керамические, ...

Ну, спорить не стану, всётки, 20 лет прошло, но методика принятия решения была именно такой. А вот соседи геофизики плотно сели на PIC, поскольку он живёт при 100градусах по паспорту.
В принципе, мне по барабану бирки изготовителей, было бы удобно работать. Ну, и цена, конечно, в случае серийного производства.

Цитата(rx3apf @ Aug 10 2007, 13:00) *
... Попробовав RISC, на CISC уже обратно не тянет совершенно. И как я раньше любил Z80 ?

Ну, меня тоже раз взяла ностальгия по PDP-11...попробовал одну задачку на MSP430 сделать, на 149-м. Дык он Меге проиграл по быстродействию раза в два, штоле, я и забил. А 51-я машина мне очень нравилась. Особенно после 48-й. А Z8 не щупал ни разу, Z80 - само собой, у кого ж Синцлаира не было!
defunct
Цитата(Прохожий @ Aug 10 2007, 01:28) *
А корпуса? У большинства ноги через 0.65 мм. Если руки кривые, то прототип изготовить практически невозможно.

0.65 мм это до ужаса много.
большинство - 0.5 мм, пайка гораздо быстрее чем DIP40, т.к. сводится к 4-м жирным "ляпам" по сторонам обычным паяльником, и потом сбор остатков.

Но встерчаются и PLCC варианты (например LPC2103).
rx3apf
Цитата(defunct @ Aug 10 2007, 16:54) *
0.65 мм это до ужаса много.
большинство - 0.5 мм, пайка гораздо быстрее чем DIP40, т.к. сводится к 4-м жирным "ляпам" по сторонам обычным паяльником, и потом сбор остатков.

Но встерчаются и PLCC варианты (например LPC2103).

Проблема - не пайка как таковая. Проблема - плата. Хотя теперь с этим все проще...

Цитата(pokos @ Aug 10 2007, 13:34) *
Ну, спорить не стану, всётки, 20 лет прошло, но методика принятия решения была именно такой.

Вообще-то еще и десяти лет не прошло wink.gif

Цитата(pokos @ Aug 10 2007, 13:34) *
Ну, меня тоже раз взяла ностальгия по PDP-11...попробовал одну задачку на MSP430 сделать, на 149-м. Дык он Меге проиграл по быстродействию раза в два, штоле, я и забил.

Да, с быстродействием у 430 не все так хорошо. Но если вспомнить, что AVR при малых напряжения питания тоже особенно быстродействием не отличается, то примерно паритет. ARM их всех порвет...

Да, кстати о быстродействии - PIC выиграет у AVR при равной тактовой при длинных сдвигах и сравнениях (всякие там корреляторы и многоразрядная арифметика), но тоже - в определенных рамках разрядности. И, опять же, MSP430 обойдет их...
SasaVitebsk
Цитата(oran-be @ Aug 10 2007, 08:14) *
Я заметил одну вещь. Никакое МК ядро не имеет столь фанатично преданных поклонников, как ядро АВР. Причем, повторюсь, в основном это те, кто сразу с него начал, либо те, кто еще не успел присесть на другие ядра. Остальные же, кто реально работает с несколькими типами МК, обычно не испытывают особого восторга от АВР. Что-то хорошо, что-то плохо. То же самое они обычно и говорят про другие типы МК, даже про те, с которых начинали. В чем же причина фанатизма?
Есть идея. Всем приверженцам АВРов собраться и пойти в ветку PICов, или 51-х, или сразу в обе и устроить там, открыв парочку горячих тем. maniac.gif А то там что-то скучновато.


Не хочу отвечать за всех, но думаю Вы не правы. Большинство AVR-щиков как раз более прогресивно настроены и совершенно не фанатеют от AVR. Именно этим и объясняется то, что в своё время они перешли на новые камни. Сейчас я сделал новый контроллер в двух вариантах на м64 с кучей обвески и на LPC2106(ARM7). Цель простая. Пока будет выпускаться на AVR (там прога будет практически без изменений с предыдущим вариантом) попробую перейти на LPC. К концу года попробую наваять вариант на AVR32. В моей задаче можно очень точно оценить реальную производительность. Вот я оценю и сравню её на нескольких камнях. И если Вы обратите внимание, то очень многие в данной ветке работали уже или планируют работать на ARMах.

Так кто же из нас фанат?

Единственное что объединяет всех AVR-щиков это нелюбовь к PICам. Как многие здесь уже отметили, совершенно не вижу повода менять AVR на PIC. Пока не вижу. Ну не нравится мне их подход. Уж извините. Незнаю делали ли их инопланетяне, но что-то левое у них есть. Вас бросает в дрожь от виртуальных команд, а меня от виртуальных констант, виртуальных регистров и прочей белетристики. За страничную организацию памяти (которую успешно перенесли доработав в SX18 и т.д.) отдельное спасибо разработчикам. Работа с таблицами данных в PIC16 - это (как писал Гашек) "яркий пример того, какие ослы ещё рождаются под луной".
mse
Цитата(rx3apf @ Aug 10 2007, 18:42) *
Да, кстати о быстродействии - PIC выиграет у AVR при равной тактовой при длинных сдвигах и сравнениях (всякие там корреляторы и многоразрядная арифметика), но тоже - в определенных рамках разрядности. И, опять же, MSP430 обойдет их...

Оба-на...;О) Каким местом он выиграет? Как? Своим единственнвм кумулятором? Очень свежая мысль. ;О)
Особенно свежо звучат "сравнения... и всякие там корреляторы и многоразрядная арифметика"
rx3apf
Цитата(mse @ Aug 10 2007, 21:31) *
Оба-на...;О) Каким местом он выиграет? Как? Своим единственнвм кумулятором? Очень свежая мысль. ;О)

Тем, что не надо перезагружать данные из RAM в рабочие регистры, разве это не очевидно ? Т.е. если у AVR мы уместимся в регистрах - все хорошо и быстро. Не уместились - и будь любезен выложи два такта на загрузку из памяти и еще два - на укладку обратно в память. На PIC16 я же спокойно сдвину, скажем, 512-битный регистр простым линейным куском из 64 команд, и займет это 64*4 такта. В случае AVR - займет 80 тактов. Но _такой_ пример - да, высосан из пальца, реально не требовалось. А вот корреляционный детектор для приемника Smartrunk-2 - делал (переносил с PIC16), оказалось более ресурсоемко (5 32-битных сдвиговых регистров).
Обращаю внимание - для сдвига не нужно даже этого "единственного аккумулятора".

Цитата(mse @ Aug 10 2007, 21:31) *
Особенно свежо звучат "сравнения... и всякие там корреляторы и многоразрядная арифметика"

Какое слово непонятно ?
oran-be
Цитата(SasaVitebsk @ Aug 10 2007, 19:39) *
Как многие здесь уже отметили, совершенно не вижу повода менять AVR на PIC. Пока не вижу. Ну не нравится мне их подход. Уж извините. Незнаю делали ли их инопланетяне, но что-то левое у них есть. Вас бросает в дрожь от виртуальных команд, а меня от виртуальных констант, виртуальных регистров и прочей белетристики. За страничную организацию памяти (которую успешно перенесли доработав в SX18 и т.д.) отдельное спасибо разработчикам. Работа с таблицами данных в PIC16 - это (как писал Гашек) "яркий пример того, какие ослы ещё рождаются под луной".

Какие такие виртуальные константы и виртуальные регистры? И я не писал, что меня в бросает в дрожь от Атмело-АВРовских виртуальных команд. Это совсем другое ощущение.
Похоже, вы не первый, кто ругает PIC'и, не попробовав на них реализовать что-нибудь более менее серьезное. Мое мнение - более элегантной и выразительной системы команд, чем у PIC16 и у PIC18(естественно) нет ни у одного другого ядра. Из мне известных, конечно. Поэтому не стоит сравнивать разработчив Микрочипа с австровенгерскими солдафонами начала прошлого века.
Я могу написать, на чем у нас загнулся АВР конкретно. Очень распространенная вещь - логический контроллер. Основа логического ядра - битовый массив, над которым производятся логические операции. АВР нормально работает, до тех пор, пока размер битового массива не превышает размер, который С компилятор может затолкать за раз при вызове функции - байт 8-12 примерно. После этого он за счет того, что ему мостоянно надо перезагружать данные, он начинает так тормозить, что его не точто имеет PIC16, которому для произведения этих самых логических операций вообще данные не надо двигать. И использовать аккумулятор.
Вследствии чего наши в прошлом приверженцы АВРов все таки изменили свое мнение. относительно преимуществ АВРов и недостатков PIC'ов.
ozzy
ZZZzzzz... 07.gif 07.gif 07.gif
Я тут поотсутсвовал немножко...
Как говорил кот Леопольд
Цитата
Ребята давайте жить дружно
beer.gif

У каждого камня есть свои сильные и слабые стороны и не стоит из за этого ругаться.

Предлагаю модератору закрыть тему как совершенно бесполезную
zltigo
Цитата(ozzy @ Aug 10 2007, 22:52) *
Предлагаю модератору закрыть тему как совершенно бесполезную

Не считаю ее бесполезной - в чужой огород тоже надо заглядывать. Обсудение, пока по крайней мере,
держится в рамках и количество явного (от меня в том числе sad.gif ) офтопика не более 25%.
Пусть пока поживет. Ладно?
SasaVitebsk
Цитата(oran-be @ Aug 10 2007, 22:31) *
Какие такие виртуальные константы и виртуальные регистры? И я не писал, что меня в бросает в дрожь от Атмело-АВРовских виртуальных команд. Это совсем другое ощущение.
Похоже, вы не первый, кто ругает PIC'и, не попробовав на них реализовать что-нибудь более менее серьезное. Мое мнение - более элегантной и выразительной системы команд, чем у PIC16 и у PIC18(естественно) нет ни у одного другого ядра. Из мне известных, конечно. Поэтому не стоит сравнивать разработчив Микрочипа с австровенгерскими солдафонами начала прошлого века.

Перечитайте ещё раз написанное вами. И кто же из нас двоих фанат?

Как то я начал делать одну тему на PIC. Не знаю как вы пишете, и в курсе ли вы, что есть такой способ координального ускорения вычислений, как различные табличные методы. Ими пользуюсь как на ASM так и на C. Найболее известный пример - вычисление CRC табличным способом. В некоторых программах это, практически, единственно возможный способ. Таблицы иногда в двое и больше превышают длину программы. Когда я попытался найти команду аналогичную LPM Rxx,X+ (для AVR) либо MOVC a,@a+dptr(для x51), то был удивлён и как это осуществляется и сколько на это тратится. Сейчас глянул - да в PIC18 ввели специальную команду! Это большой успех!

Цитата
Я могу написать, на чем у нас загнулся АВР конкретно. Очень распространенная вещь - логический контроллер. Основа логического ядра - битовый массив, над которым производятся логические операции. АВР нормально работает, до тех пор, пока размер битового массива не превышает размер, который С компилятор может затолкать за раз при вызове функции - байт 8-12 примерно. После этого он за счет того, что ему мостоянно надо перезагружать данные, он начинает так тормозить, что его не точто имеет PIC16, которому для произведения этих самых логических операций вообще данные не надо двигать. И использовать аккумулятор.
Вследствии чего наши в прошлом приверженцы АВРов все таки изменили свое мнение. относительно преимуществ АВРов и недостатков PIC'ов.


Не надо патетики. Просто приведите пример. Место где у вас "загнулся" AVR. К слову, хотя я не собираюсь препираться, передача большого числа параметров в процедуру и обратно даже на IBM не приветствуется. А на однокристалке просто не сталкивался с такими проблемами. Но, как говорится, надо - значит надо. Уговорили. Хоть и не корректно выдирать отдельные куски программы, но тем не менее выдирите кусок из проги на си с вашей компиляцией. Посчитаем. До сих пор вы, на сколько я успел заметить, не привели ни одного куска, где был бы виден выигрыш PICа. Всё как-то проигрыш. Причём не единицы - а десятки процентов. Так обоснуйте ваши слова или просто прекратите пустую болтовню.
ReAl
Цитата(oran-be @ Aug 10 2007, 21:31) *
Я могу написать, на чем у нас загнулся АВР конкретно. Очень распространенная вещь - логический контроллер. Основа логического ядра - битовый массив, над которым производятся логические операции.
Ну так естественно. Ярко выраженный перекос в сторону конкретных операций.
В случае другого ярко выраженного перекоса - массивы, несколько таблиц в ПЗУ (сильно ускоряющих алгоритм), устройства на внешней шине - пик не то что АВР, пик16с64 проиграл классическому 51-му (i87c51FA). Я уже и так, и сяк, и с разворотом - ну никак.
До отрисовки схемы выписывал на асме критические места, считал такты.
А 51-ый одну табличку по movc a, @a+dptr, вторую по movc a, @a+PC - и все довольны несмотря на то, что 51-ый по периодам кварца на инструкцию грубо в три раза тормознее.
Что-то ещё быстрее (i196, i186) смысла не было ставить - 51-ый успел.
Так в той байде у меня в 96 году пик и стоял контроллером спящего режима плюс некоторая "периферия" как I2C slave для 51-го.
А потом AVR-ки пошли и когда пик18-ые появились - мне уже как-то смысла не было на них перелазить.
Вот может на пик24 гляну ближе, но у них с пик16/18 только фамилии похожие.
SasaVitebsk
:=======================================================
PS: Попробуйте реализовать на PIC16 - пусть все оценят "элегантность". Пример реальный реализованный мной на atmega8-8МГц. Есть 6 стрелок (6 шаговых двигателей). Одна из задач - простая. Поскольку шкалы неравномерные, то я делаю простую перекодировку из 8-ми битного значения АЦП в непосредственное значение положения стрелки, ч/з массив. Значение положения стрелки в микрошагах значительно превышает 8 бит. То есть имеем 6 таблиц размерностью 256*2 байта.

Я не вылизывал так как это голова.

Вот что получилось у меня.
(Кстати зарэмлено использование оставшихся двух бит от 10-битного АЦП, для поиска промежуточного значения м/у двумя положениями стрелки. Если не лениво, то можете показать и превосходство математики PIC smile.gif )

Код
;Вычисление положения стрелки по среднему значению


    ldi        Xl,low(MADC_SR); В Х массив средних значений
    ldi        Xh,high(MADC_SR); В Х массив средних значений
    ldi        Yl,low(MStrel); В Y массив значений стрелок
    ldi        Yh,high(MStrel); В Y массив значений стрелок
    clr        nstrel        ; обрабатывать сначала

Headc:

    ld        wl,X+    ; Прочитать значение
    ldi        Zl,low(TabStrel*2); Загрузить адрес таблицы пересчёта
    ldi        Zh,high(TabStrel*2)

    add        Zl,wl    ; Смещение в массиве пересчёта на значение
    adc        Zh,nstrel; выбираем таблицу в зависимости от стрелки
    add        Zl,wl    ; Смещение в массиве пересчёта на значение *2
    adc        Zh,nstrel; умноженная на два (массив 512 байт)

    lpm        wl,Z+    ; читаем слово
    lpm        wh,Z+
;    lpm        wxl,Z+    ; и ближайшее слово

;    sub        wxl,wl    ; вычисляем разницу (не более 255)
;    ld        wxh,X+    ; Прочитать хвостик (дробь)
;    mulsu    wxl,wxh    ; поделить разницу
;    ldi        wxh,high(0);
;    sbrc    r1,7    ; размножить знак
;    ldi        wxh,high(-1); на второй байт

;    add        wl,r1    ; Скорректировать значение
;    adc        wh,wxh

    cli                ; Запрещ. прерыв. (избежать ошибки)
    st        Y+,wh    ; Сохраняем
    st        Y+,wl
    sei                ; разрешаем прерывания

    inc        nstrel    ; следующая стрелка

    cpi        nstrel,6; Конец массива?
    brne    Headc    ; если нет, то повторить
    wdr                    ; сбросить WDT


HeadcEnd:            ; Конец второй секции
Прохожий
Цитата(zltigo @ Aug 10 2007, 12:11) *
Понимаете, что "напринималось в буфер" это настолько мелкая проблема на фоне остальных, что она будет решаться средствами отладки ориентированными на все остальное. В моем случаее это обязательная отладочная консоль. Причем консоль, это отдельная задача с определенным проиритетом и сепень ее загружености не приводит к существенным временным перекосам основного алгоритма. Память под буфера выделяется через менеджер памяти, что позволяет всегда у него спросить информацию о блоках памяти и их владельцах не разбираясь с конкретным мапфайлом. Зачастую буфера не абстрактны а обслуживаются, например, системным механизмом очередей, что в свою очередь позволяет запросить интимную информацию и у менеджера очереди. Ну а дальше - запросить дамп памяти в которой находится буфер и все.
Зачем мне в описанной реальной системе для посмотреть "напринималось в буфер" внутриcхемный отладчик smile.gif?. На самом деле, я "сырые" буфера и не смотрю в принципе - когда более высокие уровни будут разбираться с тем, что "напринималось", у них и попрошу уже форматированную распечатку.

Дык, в вашем случае разрабатывается не просто большая, а, скажем так, огромная программно аппаратная система и, наверное, не один год. Тогда наличие отладочной консоли в том или ином виде абсолютно обосновано. В моем же случае работа ведется с двумя, максимум четырьмя буферами. И нет смысла организовывать спец. консоль. Для этих целей и нужен отладчик, причем не особо сложный. ICD2 и иже с ним, в принципе, удовлетворяют всем требованиям.
Кроме этого, я не большой любитель всяческих ОС на столь микроскопических девайсах, которыми являются как AVR, так и PIC. Хотя в Вашем случае применение ОС абсолютно оправданно.

Цитата(ReAl @ Aug 11 2007, 01:07) *
Вот может на пик24 гляну ближе, но у них с пик16/18 только фамилии похожие.

Конечно, в 24-х PICах много чего нового, но явная преемственность тоже прослеживается. Так называемая file registres адресация - прямое наследие 16-х и 18-х PICов.
defunct
Цитата(oran-be @ Aug 10 2007, 22:31) *
АВР нормально работает, до тех пор, пока размер битового массива не превышает размер, который С компилятор может затолкать за раз при вызове функции - байт 8-12 примерно.

lol.gif
Посмеялся smile.gif "байт 8-12 примерно". Напомнило фразу автора banned курса - "в IAR 1 байт равен двум байтам AVR примерно."

Зачем же ж массив пихать как параметр функции?
Передавайте через указатель будет быстро.

У меня HDLC прием/передача на лету обрабатывается авркой в фоне. Битовых операций там просто "немеряно". И пакеты всяко больше 12-ти байт.

Цитата(Прохожий @ Aug 11 2007, 00:50) *
Кроме этого, я не большой любитель всяческих ОС на столь микроскопических девайсах, которыми являются как AVR, так и PIC. Хотя в Вашем случае применение ОС абсолютно оправданно.

ОС упрощают работу настолько же, насколько упрощает жизнь C в сравнении с ASM'ом. На микроскопических чипах (хотя AVR бывает и отнюдь не микроскопическим, к примеру m2560 - 256k флеша это уже достаточно большой проект исходников на C эдак на 1-2Mb), применение микроскопических ОС - окупается и оправдывается временем разработки.
Прохожий
Цитата(defunct @ Aug 11 2007, 02:21) *
ОС упрощают работу настолько же, насколько упрощает жизнь C в сравнении с ASM'ом. На микроскопических чипах (хотя AVR бывает и отнюдь не микроскопическим, к примеру m2560 - 256k флеша это уже достаточно большой проект исходников на C эдак на 1-2Mb), применение микроскопических ОС - окупается и оправдывается временем разработки.

Не надо со мной про ОСы. По отношению к ним я абсолютно необъективен.
Немного bb-offtopic.gif , если позволите.
На днях закончил кусок программы для Винды, связанный с обменом данными через DDE сервер, разработанный одной очень уважаемой конторой. Для того, чтобы все это устойчиво заработало пришлось убить три дня своего времени и перелопатить туеву хучу вторичной (абсолютно бесполезной) информации, к которой я отношу описание функций ОС (в данном случае XP).
И потом, моя методика программирования для МК и так включает в себя такие понятия, как процесс, флаг (мьютекс, семафор), событие. Только выстраивается это все непосредственно под решаемые задачи и железо конкретного МК минуя ОС.
Насчет С могу сказать только одно. Упрощение жизни заметил только тогда, когда решал задачи, связанные с расчетом полиномов термопар, а так - разницы особой нет. Трудности в правильном постороении алгоритма, а не в том на чем он отображен впоследствии.
Впрочем, это мое личное мнение, никому ненавязываемое.
mse
Цитата(rx3apf @ Aug 10 2007, 21:43) *
Тем, что не надо перезагружать данные из RAM в рабочие регистры, разве это не очевидно ? Т.е. если у AVR мы уместимся в регистрах - все хорошо и быстро.

Очень хорошо вы себе ответили:
Цитата
Но _такой_ пример - да, высосан из пальца, реально не требовалось.
Я именно об этом ;О) В том смысле, что и не потребуется. А если потребуется, то сто пудов, десяток-другой лишних тактов погоды не сделает и не испортит. Максимум, чего может плохого приключиться, это поделить 64/64. Но до такой жизни ещё дойти надо суметь. ;О)
Цитата
Какое слово непонятно ?

Да мне-то все слова понятны. ;О) В частности, ядро кореллятора(в общем случае) - операццыя МАС. Например такая: 16s*16s=32s+АСС40бит.(s-signed) А в особо весёлых случаях и 16s*24s приходится накручивать, но это уже при фильтераццыи...
Распишете сами или мне помочь? И этта...выводы тоже. ;О) Бо вот в этом случае десяток лишних тактов вырождается в сотни, а то и тыщи на тот-же кореллятор. Или какой фильтер. Или ДПФ какое. И вот мы уже в частоту дискретизаццыи не лезем. ;О)
Ну и про многоразрядную арифметику тоже... мне в жизни не потребовалось складывать-вычитать-делить ничего больше 64р. Да и то, потому, что промежуточный результат такой получался.
1S49
quote name='ozzy' date='Aug 10 2007, 23:52' post='281981']
ZZZzzzz... 07.gif 07.gif 07.gif
Я тут поотсутсвовал немножко...
Как говорил кот Леопольд beer.gif

У каждого камня есть свои сильные и слабые стороны и не стоит из за этого ругаться.

Предлагаю модератору закрыть тему как совершенно бесполезную
[/quote]

М-да, только AVR-щик может открыть тему: “XXX – признали!”. Никак не могу понять, откуда у них развился такой комплекс собственной неполноценности?
kamedi_clab
Цитата(oran-be @ Aug 9 2007, 00:10) *
По производительности PIC18 имеет АВР по полной, несмотря на в 2 раза меньшее значение MIPS.


А что не в 4 ? вроде так на самом деле есть.

Цитата(oran-be @ Aug 9 2007, 00:10) *
Загрузка-выгрузка все сводит на нет.


Поясните если не трудно.
Petka
Забавно, но мне показалось, что многие из PICщиков отметившихся в этой теме пишут в основном на АСМе. Интересно, есть ли среди PICшиков те, кто реально использует для программирования Си? Было бы интересно обсудить преимущества и недостатки AVR/PIC именно с ними.

Итак, уважаемые, кто программирует PIC в основном на Си, откликнитесь!
Denisvak
smile.gif читал читал... вроде люди взрослые а об таком спорите!!!
Такое очучение что большинство ораторов тут собирает просто домашние поделки...ну тогда можно спорить сколько угодно - каждый кулик свое болото хвалит smile.gif

Как мне кажется камешек для проекта надо выбирать не только из прынцыпа что я вот его знаю на все 100% вот и заложу его в разработку - о таком большинстве я и говорю. Но согласитесь...выбор зависит от самого проекта...в одном не нужна максимальная производительность в пользу высокой надежности, в другом важна цена..., какой-то проект нужно сделать очень быстро и Вы конечно возьмете то что вам больше знакомо, другому заказчику важна надежность и качество и тип камешка он Вам диктует сам считая его лучшим....

а так ИМХО об г.... разговор
зря тему в лес угнали...
=GM=
2SasaVitebsk. Маленький вопросик по этому фрагменту
Цитата(SasaVitebsk @ Aug 10 2007, 21:12) *
PS: Попробуйте реализовать на PIC16
Код
      clr    nstrel     ; обрабатывать сначала
headc:
      . . . . . . . .
      inc    nstrel     ; следующая стрелка
      cpi    nstrel,6;   Конец массива?
      brne   headc      ; если нет, то повторить

Почему бы цикл не организовать так
Код
      ldi    nstrel,6   ; обрабатывать сначала
headc:
      . . . . . . . .
      dec    nstrel     ; следующая стрелка
      brne   headc      ; повторить, если не все стрелки

Всё-ж-таки экономия одного оператора.

Что касается реализации вашего фрагмента на пик18, странно, но у меня получилось то же самое количество машинных циклов, как и у вас, вот такие фактики в мире галактики...На мой взгляд, Пик начнёт проигрывать АВРу при арифметических операциях, там где придётся использовать его единственный аккумулятор WREG.
gormih
Цитата(Denisvak @ Aug 11 2007, 14:34) *
зря тему в лес угнали...




Это бесполезно smile.gif

Бывает так - люди не хотят ничего слышать о реальности. Им подавай удовлетворение их амбиций - пускай спорят smile.gif
oran-be
Цитата(SasaVitebsk @ Aug 10 2007, 19:39) *
Так кто же из нас фанат?

Похоже, имеет место программирование, но совсем не на АВР smile.gif.
Чем же фанатик отличается от свободомыслящего Хомо Сапиенс? Так как мы в ветке АВР, то можно абстрактно представить, что группа программистов написала жутко универсальную программу для анализа и обработки неких входных данных, имеющих широкий спектр протоколов, поступающих, скажем по USART. В железо заложили, скажем АТМегу2560 и заполнили 220к из 256 возможных. Обработчик построили в виде множества функций, рассчитанных каждая на свой тип протокола, вызываемых при помощи таблицы переходов. Индекс в таблице переходов вычисляет анализатор, который при помощи наложения масок обрабатывает часть входных данных. Так вот, чтобы получить "фанатично настроенный" процессор, необходимо перезаписать таблицу переходов, заполнив ее указателем на одну-единственную функцию, либо в анализаторе свести все маски к одной. Естественно, при таком раскладе львиная доля входных данных будет восприниматься совершенно неадекватно. И большая часть заложенного кода окажется бесполезной.
Это все к тому, что определенная часть поклонников АВР почему то при анализе входных данных использует одну и ту же маску: "AVR - the best", а в таблице переходов активным остается один вектор, обрабатывающий сигнал "На нас напали". Очевидно в итоге всего этого неадекватного восприятия начинают приводится куски кода, якобы представляющие верх элеганости, хотя на самом деле это тривиальная до зубной боли задача "переслать два байта", на С она бы заняла ни много ни мало, а целую строчку в тесте, а компилятор выдал бы код не хуже. (Может это есть тонкий прикол на тему "как два байта переслать"?)
Пытаясь достучатся до адекватного восприятия, повторюсь - "АВР признали" - это удивительно не потому, что ядро АВР плохое, а потому, что у фирмы Атмел маркетинг бежит впереди качества, в результате чего годика так этак 2-3, до появления Мега8, они выпускали МК, несовместимые с устойчивой продолжительной работой. И не признавали этого ну никак. И глюки железячные у АВР такие, каких нигде нет. И внедрение маркетинга в техдокументацию вызывает дополнительную путаницу.
Цитата(bodja74 @ Aug 9 2007, 11:19)
2 С периферией для начала нужно научиться работать а потом хаять ,TWI выдаст ошибку в регистре статуса если что не так ,я уже не говорю про ситуации с NACK ,и правильно делает что затыкаеться,нечего инфу тупо гнать.

Совет умный про анализ результата. Но анализировать можно сколько угодно. но если модуль аппаратно зависает, то результат анализа можно засунуть в одно место. Много помогает анализ кода ошибки синего экрана смерти в Виндоуз? NACK - нормальный сигнал на шине, он не должен приводить к зависанию модуля.
WHALE
Цитата(oran-be @ Aug 12 2007, 16:41) *
NACK - нормальный сигнал на шине, он не должен приводить к зависанию модуля.

Удивительное дело,я всегда считал,что у AVR очень удачный модуль TWI.
Вас уже не первый раз призывают перейти от слов к делу.
Приведите,плиз,ваш код работы с квадратной шиной,где NASK вешает модуль,желательно на С.
µµC
Голосовалка, типа что круче сегодня?

PIC24 (+dsPIC33) однозначно и чисто конкретно рулят по всем значимым характеристикам включая цену. Это для сегмента занимаемого мегами32 - 128.
И в самом деле, разве есть еще чудаки, закладывающие в новый проект m128, или, скажем, 5V питание? Правильно, нету, перевелись уже - повымирали от избытка холестерина в мозге.

m48 - m8 однозначно рулят в своем сегменте.

Кстати, PIC18F24J10 это аналог m16 по флешу, рам, да и по цене тоже.
oran-be
Цитата(WHALE @ Aug 12 2007, 16:35) *
Удивительное дело,я всегда считал,что у AVR очень удачный модуль TWI.
Вас уже не первый раз призывают перейти от слов к делу.
Приведите,плиз,ваш код работы с квадратной шиной,где NASK вешает модуль,желательно на С.

Код
BYTE volatile byTWIctrl;
BYTE volatile byTWIstate;

      // State byte. Default set to TWI_NO_STATE.
static BYTE* pTWItrans;         // указатель на текущий байт
static BYTE ctTWI;             // счетчик приема-передачи
static BYTE byDisp;            // смещение в подчиненном устройстве
static BYTE bySlaveAddr;

..............................................................
  функции всякие разные
..................................................................
// сам поток собственно

SIGNAL(SIG_2WIRE_SERIAL){
    switch (TWSR){
    //------------------------------------------------------------------------
        case TWI_START:             // START has been transmitted
        case TWI_REP_START:         // Repeated START has been transmitted
                    TWDR = bySlaveAddr;
            if(byTWIctrl & TWS_READ_NOW)  TWDR |= 1;
                     TWCR = (1<<TWEN)|                                 // TWI Interface enabled
                            (1<<TWIE)|(1<<TWINT)|                      // Enable TWI Interupt and clear the flag to send byte
                               (0<<TWEA)|(0<<TWSTA)|(0<<TWSTO)|           //
                               (0<<TWWC);
                break;
    //------------------------------------------------------------------------
        case TWI_MTX_ADR_ACK:       // SLA+W has been tramsmitted and ACK received
                TWDR = byDisp;
                TWCR = (1<<TWEN)|                                 // TWI Interface enabled
                        (1<<TWIE)|(1<<TWINT)|                      // Enable TWI Interupt and clear the flag to send byte
                           (0<<TWEA)|(0<<TWSTA)|(0<<TWSTO)|           //
                           (0<<TWWC);
            break;
    //----------------------------------------------------------------------
        case TWI_MTX_DATA_ACK:      // Data byte has been tramsmitted and ACK received
            if(byTWIctrl & TWS_READ_OP){ // проверка на операцию записи
                       byTWIctrl |= TWS_READ_NOW;
                    TWCR = (1<<TWEN)|                             // TWI Interface enabled.
                            (1<<TWIE)|(1<<TWINT)|                  // Enable TWI Interupt and clear the flag.
                            (0<<TWEA)|(1<<TWSTA)|(0<<TWSTO)|       // Initiate a START condition.
                            (0<<TWWC);
                break;
            }
              if (ctTWI){        // передача данных
                    ctTWI--;
                    TWDR = *pTWItrans;
                pTWItrans++;
                TWCR = (1<<TWEN)|                                 // TWI Interface enabled
                        (1<<TWIE)|(1<<TWINT)|                      // Enable TWI Interupt and clear the flag to send byte
                           (0<<TWEA)|(0<<TWSTA)|(0<<TWSTO)|           //
                           (0<<TWWC);                                 //
              }else{                    // Send STOP after last byte
                    byTWIctrl = 0;                 // Set status bits to completed successfully.
                    TWCR = (1<<TWEN)|                                 // TWI Interface enabled
                               (0<<TWIE)|(1<<TWINT)|                      // Disable TWI Interrupt and clear the flag
                               (0<<TWEA)|(0<<TWSTA)|(1<<TWSTO)|           // Initiate a STOP condition.
                               (0<<TWWC);                                 //
              }
              break;
    //-----------------------------------------------------------------------------
        case TWI_MRX_DATA_ACK:      // Data byte has been received and ACK tramsmitted
                  *pTWItrans = TWDR;
                pTWItrans++;
        case TWI_MRX_ADR_ACK:       // SLA+R has been tramsmitted and ACK received
                ctTWI--;
              if (ctTWI){                  // Detect the last byte to NACK it.
                    TWCR = (1<<TWEN)|                                 // TWI Interface enabled
                               (1<<TWIE)|(1<<TWINT)|                      // Enable TWI Interupt and clear the flag to read next byte
                               (1<<TWEA)|(0<<TWSTA)|(0<<TWSTO)|           // Send ACK after reception
                               (0<<TWWC);                                 //
              }else{                    // Send NACK after next reception
                    TWCR = (1<<TWEN)|                                 // TWI Interface enabled
                               (1<<TWIE)|(1<<TWINT)|                      // Enable TWI Interupt and clear the flag to read next byte
                               (0<<TWEA)|(0<<TWSTA)|(0<<TWSTO)|           // Send NACK after reception
                               (0<<TWWC);                                 //
              }
              break;
        case TWI_MRX_DATA_NACK:     // Data byte has been received and NACK tramsmitted
                  *pTWItrans = TWDR;
                  byTWIctrl = 0;                 // Set status bits to completed successfully.
                  TWCR = (1<<TWEN)|                                 // TWI Interface enabled
                         (0<<TWIE)|(1<<TWINT)|                      // Disable TWI Interrupt and clear the flag
                         (0<<TWEA)|(0<<TWSTA)|(1<<TWSTO)|           // Initiate a STOP condition.
                         (0<<TWWC);                                 //
              break;
        case TWI_ARB_LOST:          // Arbitration lost
                byTWIctrl = 0;
                  TWCR = (1<<TWEN)|                                 // TWI Interface enabled
                          (1<<TWIE)|(1<<TWINT)|                      // Enable TWI Interupt and clear the flag
                          (0<<TWEA)|(1<<TWSTA)|(0<<TWSTO)|           // Initiate a (RE)START condition.
                          (0<<TWWC);                                 //
                  break;
//        case TWI_MTX_ADR_NACK:      // SLA+W has been tramsmitted and NACK received
//        case TWI_MRX_ADR_NACK:      // SLA+R has been tramsmitted and NACK received
//        case TWI_MTX_DATA_NACK:     // Data byte has been tramsmitted and NACK received
        //    case TWI_NO_STATE              // No relevant state information available; TWINT = “0”
//        case TWI_BUS_ERROR:         // Bus error due to an illegal START or STOP condition
        default:
                      byTWIstate = TWSR;                                     // Store TWSR and automatically sets clears noErrors bit.
                    byTWIctrl = 0;                                    // Reset TWI Interface
                      TWCR = (1<<TWEN)|                                 // Enable TWI-interface and release TWI pins
                             (0<<TWIE)|(0<<TWINT)|                      // Disable Interupt
                             (0<<TWEA)|(0<<TWSTA)|(0<<TWSTO)|           // No Signal requests
                             (0<<TWWC);                                 //
    }
}

Модуль TWI не виснет, если на шине все в порядке. Но если некий слейв вдруг начинает притормаживать, в особенности если это тоже проц, с еще сырым кодом, то есть чему удивиться. У нас Меги8 работали год с PCF8563, пока батарея как то раз не разрядилась. Прога подвисла вся.
singlskv
Цитата(oran-be @ Aug 12 2007, 20:22) *
Код
//        case TWI_BUS_ERROR:         // Bus error due to an illegal START or STOP condition
        default:
                      byTWIstate = TWSR;                                     // Store TWSR and automatically sets clears noErrors bit.
                    byTWIctrl = 0;                                    // Reset TWI Interface
                      TWCR = (1<<TWEN)|                                 // Enable TWI-interface and release TWI pins
                             (0<<TWIE)|(0<<TWINT)|                      // Disable Interupt
                             (0<<TWEA)|(0<<TWSTA)|(0<<TWSTO)|           // No Signal requests
                             (0<<TWWC);                                 //
    }
}

Модуль TWI не виснет, если на шине все в порядке. Но если некий слейв вдруг начинает притормаживать, в особенности если это тоже проц, с еще сырым кодом, то есть чему удивиться. У нас Меги8 работали год с PCF8563, пока батарея как то раз не разрядилась. Прога подвисла вся.

Открою Вам небольшой секрет на TWI_BUS_ERROR необходимо
отвечать выставлением TWSTO в TWCR в 1 , это сбрасывает ошибку шины.
Подробнее не смотрел, это просто сразу бросилось в глаза.

Так что, куририте даташиты внимательней, а потом обвиняйте производителя в глючности.
bodja74
Цитата(oran-be @ Aug 12 2007, 19:22) *
Модуль TWI не виснет, если на шине все в порядке. Но если некий слейв вдруг начинает притормаживать, в особенности если это тоже проц, с еще сырым кодом, то есть чему удивиться. У нас Меги8 работали год с PCF8563, пока батарея как то раз не разрядилась. Прога подвисла вся.

Вы знаете ,я примерно такой код в бутлоадере применил,(ну шил внешнюю память через бут),
правда без прерывания smile.gif тоесть у меня был напряг с размером проги бута smile.gif
А вообще такие вещи пишутся немного солиднее ,он у вас и повиснет ,но до этого регистр статуса вам даст ТРИЖДЫ знать ,что уходим в ступор smile.gif ,а выйти ,уж кто как любит ,или по собаке или лампочками моргаем или молча перезапускаемся.
Если слейв притормаживает ,тем более если слейв таже мега ,он аппаратно дает знать об этом мастеру по шине.

Вообще проблем по TWI я не замечал,а вот проблем из за освоения TWI и пониманием его работы - это было много раз ,не зря я выше писал "сначала нужно искать ераты своей программе smile.gif"

Ну отошли совсем от темы.
Чем приводить "скоростные" коды ,кто кого скоростнее smile.gif просто достаточно посмотреть таблицу ,какие команды за сколько тактов выполняются ,и сравнить ,если таких команд нет ,выяснить сколько займот команд выполнение такой же операции ,и сразу все станет ясно ,где впереди где сзади smile.gif
Dog Pawlowa
Цитата(Petka @ Aug 11 2007, 12:24) *
Итак, уважаемые, кто программирует PIC в основном на Си, откликнитесь!

Ну я. Один проект на PIC, и он единственный - на С. 100 % smile.gif

Даже не знаю, о каких недостатках и преимуществах тут говорят 07.gif
И вообще. Структура проектирования у каждого давно сложилась - у кого-то ОС, у кого-то автоматы, у кого-то что-то вообще примитивное. Под задачу выбирается контроллер с нужной производительностью, чтобы не ломать собственную структуру, в которой удобно и понятно.
Разговор действительно ни о чем.
WHALE
Цитата(oran-be @ Aug 12 2007, 20:22) *
Модуль TWI не виснет, если на шине все в порядке. Но если некий слейв вдруг начинает притормаживать, в особенности если это тоже проц, с еще сырым кодом, то есть чему удивиться. У нас Меги8 работали год с PCF8563, пока батарея как то раз не разрядилась. Прога подвисла вся.

Милейший,вы что,издеваетесь?Илм действительно не понимаете,что пишете полный бред?Как может севшая батарея RTC повесить шину!?Ведь при включении питания девайса RTC должны перейти с бата-
рейного питания на рабочее.Имхо,у вас или диод на рабочее питание неправильно стоит или его нет во-
все.
Вам тут уже дали совет как корректно сбросить модуль.Код в обработчике в остальном вроде правильный.
Я тоже работаю c RTC филипса,тока PCF8583,но не суть.
Сделано уже штук 20 девайсов,стоят в необслуживаемых будках.Этой зимой тоже умерло парочка ба-
тарей,ничего не зависло.Я в менюшке установки времени при записи значений в регистры еще пишу
в ОЗУ ПСФ-ки еще тест-с адреса 10 тест лестница.И дальше при каждом включении в старт-апе прове-
ряю тест,и если не проходит,я с часами просто не работаю и отсылаю смс-сбой часов.
Так-что вы меня пока што убедили тока в старой истине-умелыми руками мона и столб уронить.
Dog Pawlowa
Цитата(µµC @ Aug 12 2007, 16:45) *
И в самом деле, разве есть еще чудаки, закладывающие в новый проект m128, или, скажем, 5V питание? Правильно, нету, перевелись уже - повымирали от избытка холестерина в мозге.

Ну я. Живой. А какая, по Вашему, альтернатива?
WHALE
Цитата(Dog Pawlowa @ Aug 12 2007, 22:10) *
Ну я. Живой. А какая, по Вашему, альтернатива?

+1.
zltigo
Цитата(Dog Pawlowa @ Aug 12 2007, 21:05) *
Разговор действительно ни о чем.

Разговор о том, что НЕ НАДО залезать в каое-то определенное болото, пусть оно и кажется пока теплым (а когда уже не совсем устраивает, пусть даже подсознательно, похоже некоторые начинают себя на фанатизм накручивать). Кругозор нужно уметь раздвигать. Кругозор в контроллерах, языках, приемах программироания. Надо! А сидеть на каком-нибудь мелком контроллере в ASM и писать очевидные вещи нельзя. Для себя любимого это вредно smile.gif.
Dog Pawlowa
Цитата(zltigo @ Aug 12 2007, 21:21) *
Разговор о том, что НЕ НАДО залезать в каое-то определенное болото, пусть оно и кажется пока теплым (а когда уже не совсем устраивает, пусть даже подсознательно, похоже некоторые начинают себя на фанатизм накручивать). Кругозор нужно уметь раздвигать. Кругозор в контроллерах, языках, приемах программироания. Надо! А сидеть на каком-нибудь мелком контроллере в ASM и писать очевидные вещи нельзя. Для себя любимого это вредно smile.gif.

Хм, с каких это пор модераторы Электроникса за "пустую болтовню" вместо четко обозначенной помощи? biggrin.gif
Приучили нас тут "шаг влево, шаг вправо - побег", а сами вдруг вольницу пропагандируют? smile.gif
Прохожий
Цитата(zltigo @ Aug 12 2007, 22:21) *
Разговор о том, что НЕ НАДО залезать в каое-то определенное болото, пусть оно и кажется пока теплым (а когда уже не совсем устраивает, пусть даже подсознательно, похоже некоторые начинают себя на фанатизм накручивать). Кругозор нужно уметь раздвигать. Кругозор в контроллерах, языках, приемах программироания. Надо! А сидеть на каком-нибудь мелком контроллере в ASM и писать очевидные вещи нельзя. Для себя любимого это вредно smile.gif.

По моему личному мнению, Вы не совсем правы. Развитие себя любимого за счет смены платформы - это, на мой взгляд, переработка чего-то уже кем-то съеденного. Да, это расширение кругозора, но не в ту степь. Кто мешает на том же PICе или AVR расширять кругозор в "языках, приемах программирования", что , на мой взгляд, наиболее важно?
Объясните, в чем принципиальная разница между ARM с Linux и i486 с Windows? Программирования, по моему мнению, как такового там давно уже нет, а есть сплошное разбирательство с чужой писаниной.
zltigo
Цитата(Dog Pawlowa @ Aug 12 2007, 21:37) *
Хм, с каких это пор модераторы Электроникса за "пустую болтовню" вместо четко обозначенной помощи? biggrin.gif

Надеюсь, что эта "болтовня" кому-нибудь действительно 'четко' помочь принять стратегическое решение.
SasaVitebsk
Цитата(=GM= @ Aug 12 2007, 01:49) *
2SasaVitebsk. Маленький вопросик по этому фрагменту

Почему бы цикл не организовать так
Код
      ldi    nstrel,6  ; обрабатывать сначала
headc:
      . . . . . . . .
      dec    nstrel    ; следующая стрелка
      brne   headc     ; повторить, если не все стрелки

Всё-ж-таки экономия одного оператора.

Что касается реализации вашего фрагмента на пик18, странно, но у меня получилось то же самое количество машинных циклов, как и у вас, вот такие фактики в мире галактики...На мой взгляд, Пик начнёт проигрывать АВРу при арифметических операциях, там где придётся использовать его единственный аккумулятор WREG.


На первый вопрос я указал причину. Я не вылизывал - это голова.
На второй вопрос - ответ простой. smile.gif На PIC18 - понятно. Но человек писал, что "красивее чем система комманд PIC16 не найти." Поэтому я и просил - "продемонстрируйте красоту PIC16 на данном примере."

А в принципе, я не понимаю только одного. Это два совершенно параллельных семейства. Я абсолютно не вижу смысла перехода как в одну сторону, так и в другую. Потому, что сама работа предполагает целый цикл. И требует и отладочных средств, и наработки (в том числе и с учётом особенностей семейства), и компиляторы и прочие программные средства, а также некоторые моменты работы с поставщиками. Изменение всего этого, не то что бы вызывает особые сложности, но всётаки с этим необходимо считаться. Поэтому переход с семейства на новое семейство требует значительной причины для этого. Я не призываю сторонников PIC галопом переходить на AVR. Не понимаю почему к этому призывают меня, обвиняя в "фанатизме", при этом в данном посте совершенно нет ни одного примера который бы оправдывал такой переход. То что PIC18 выполнит приведенный мной фрагмент также - это предлог? Вот скажите мне GM? У меня atmega8 без кварца за 1.15$ получает 6 каналов АЦП и управляет стрелками на 6 шаговых двигателях. Двигателя сидят непосредственно на ножках. Испытания все пройдены и выпускаются тысячами. Наравне с PICами. Отказов не больше. И ещё один момент. Если я запаиваю atmega88, то я могу прогу отлаживать в DBGWARE. Назовите мне PIC18 c этими же характеристиками. И давайте сравним цену.


Я обозначу свою позицию и больше не вижу смысла участвовать в споре на "понятиях", так как реальных аргументов - увы не прозвучало.

Я перейду на PIC в случае реального серьёзного преимущества в данном семействе. В частности я уже примерялся к PIC24H. Кстати на мой взгляд он ближе к AVR чем к PIC16. Но буду учитывать сумму всех факторов. То есть стоимость, достовабельность, отладочные, компиляторы и прочее. Естественно я буду сравнивать с текущими кристаллами. Также я буду сравнивать и другие. В частности я просматривал и M16C и ARM7. В настоящий момент вероятность перехода мной на PIC всётаки мала. Скорее будет переход на ARM7. Но зарекаться не буду.
Dog Pawlowa
Цитата(Прохожий @ Aug 12 2007, 22:20) *
... Развитие себя любимого за счет смены платформы - это, на мой взгляд, переработка чего-то уже кем-то съеденного. Да, это расширение кругозора, но не в ту степь. Кто мешает на том же PICе или AVR расширять кругозор в "языках, приемах программирования", что , на мой взгляд, наиболее важно?..

Нет, не представляю, как можно оставаться в рамках одной платформы в более-менее разнообразных проектах. Кроме собственно ядра, есть еще и питание, аппаратные средства микроконтроллеров (порты, таймеры, АЦП и проч), корпуса и другие факторы, что заставляет менять платформу.
Какие еще приемы программирования? Лабай (сорри, только "Вокзал для двоих" закончился) на ЯВУ, вот и все приемы. biggrin.gif

Цитата(zltigo @ Aug 12 2007, 23:29) *
Надеюсь, что эта "болтовня" кому-нибудь действительно 'четко' помочь принять стратегическое решение.

Ну, решение можно принять только попробовав что-то новое. Если свободная дискуссия подтолкнет кого-то попробовать другую платформу или такой "прием программирования" как ОС, то уже хорошо.

Цитата(SasaVitebsk @ Aug 12 2007, 23:32) *
И ещё один момент. Если я запаиваю atmega88, то я могу прогу отлаживать в DBGWARE. Назовите мне PIC18 c этими же характеристиками. И давайте сравним цену.

Если быть объективным, это не аргумент. Если Вам нужна отладка в серийном изделии, то сколько же Вы их выпускаете?
µµC
Цитата(Dog Pawlowa @ Aug 12 2007, 22:10) *
Ну я. Живой. А какая, по Вашему, альтернатива?


Альтернатива это, как сразу сказал, это PIC'и.

http://www.microchip.com/ParamChartSearch/...n&pageId=75
http://www.microchip.com/ParamChartSearch/...n&pageId=75
http://www.microchip.com/ParamChartSearch/...n&pageId=75

Значительно более высокая производительность, больше памяти, более развитая периферия за те же деньги (вообще-то даже дешевле). Система команд у PIC'а (особенно dsPIC33) на фоне системы команд меги выглядит просто божественным совершенством. Система прерываний так же более развита. Средства разработки более чем доступны. Да чего уж там, они и так есть у каждого - они одинаковы для любых пиков (ICD2, пик кит 2, мплаб). Микрочиповский С компилятор на основе GCC также весьма хорош.

Для _многих_ случаев (ну не для всех конечно), 40 мипс dsPIC33 показывает большую производительность, чем 55 - 60 мипс ARM, и в качестве вычислителя и, разумеется, в качества чисто контроллерного ногодрыжества.
ivainc1789
Можно любить одного человека, а можно развести гарем... ИМХО, вопрос воспитания и мировоззрения... smile.gif
WHALE
Цитата(zltigo @ Aug 13 2007, 00:29) *
Надеюсь, что эта "болтовня" кому-нибудь действительно 'четко' помочь принять стратегическое решение.

В топике уже 10 страниц,из них 80% ни о чем.Нельзя-же считать аргументами утверждения "у AVR-щиков холестерин в моске"или утверждать о глючности кристаллов,не разобравшись ни железом,ни как правильно с ним работать. Но 20% процентов дискусси по крайней мере для меня были полезными.Скачал таблицу с PICами,посмотрел цены и возможности и был впечатлен.ИМХО,AVR медленно,но верно сливает PIC.Еще год-два,и усе-приплыли.PIC серьезно модифицировал ядро,снизил цены,да и общий выбор кристаллов по сравнению с AVR впечатляет.Такое впечатление,что ATMEL на 8-битники просто забил sad.gif Похоже,все силы брошены на АVR32.Ядро не модернизировалось с незапямятных времен,выбор кристалов почти на порядок меньше.Обещанные XMEGA в полном тумане.Короче,перспективы не радуют...
=GM=
Цитата(µµC @ Aug 12 2007, 20:57) *
Для _многих_ случаев (ну не для всех конечно), 40 мипс dsPIC33 показывает большую производительность, чем 55 - 60 мипс ARM, и в качестве вычислителя и, разумеется, в качества чисто контроллерного ногодрыжества.

Есть АВР с ТАКТОВОЙ ЧАСТОТОЙ 48 МГц, т.е. 48 МИПС в пике. Мне кажется, в сравнении с такими АВР даже dsPIC33 будет выглядеть бледновато, хотя он и 16-битный, следовательно, по большому счёту сравнивать не корректно. Что уж там говорить о пик18 и ниже.
Прохожий
Цитата(=GM= @ Aug 13 2007, 01:07) *
Есть АВР с ТАКТОВОЙ ЧАСТОТОЙ 48 МГц, т.е. 48 МИПС в пике. Мне кажется, в сравнении с такими АВР даже dsPIC33 будет выглядеть бледновато, я уж не говорю о пик18 и ниже.

Но, согласитесь, - это уже некрасиво. Просто повышать частоту. А где же работа ума?.
К стати, МИПС АВР - это не совсем одно и то же, что МИПС dsPIC33 (команда MAC, к примеру). А если учесть, что там и DMA есть...
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.