Микроконтроллер - как перспектива примочкостроения

[KMG]

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

Кстати, для станка для экспериментов лучше тогда брать макимальный чип. Тогда на нем можно будет откатать и задачи под тиньку и под максимальный вариант, так как ядро одно и тоже и большинство периферии совпадает.
Просто при разрабртке под меньший чип использовать ту периферию и те объемы памяти что есть в маленьком чипе.

Для того, что б соорудить МИДИ - тебе нужно только стандартную оптронную обвязку добавить.

А вот это как раз уже не выйдет так как к порту микроконтроллера уже подключен FTDI чип и порт используется для загрузки программ. Именно этим мне не нравится ардуино.

[Rst7]

Мелкие AVRы выигрывают у ARMов в простейших зачачах типа сервиса из за своей компактности (малоногости).

Это давно не соответствует действительности. Разве что только крайний 8миногий случай, но он очень крайний. И тут нефиг макетировать, надо сразу делать готовое изделие. Все остальные вопросы с куда большей эффективностью закрываются, например LPC11xx взамен ATMega48-88-168-328 - цена ниже(!!!) и производительность выше по всем параметрам - и разрядность выше, и мегагерц больше, и жрет меньше при той же производительности. Размер по плате - тот же.

[Rst7]

А уж защититься от одинокой КМОПки - это просто праздник

Это не просто КМОПка аля 561я серия. Это как 74AC - токи дикие, изучите нагрузочные характеристики портов ввода-вывода в даташите, там CD4xxx (561) не угадывается вообще, нет даже таких крепких TTL-серий.

[Rst7]

Если не охота связываться с смд, можно взять ту же 8-ю мегу в дипе и прилепить на макетку для экспериментов.

Я часто поступал так - припаивал прямо на ножки дипа кварц, кусочек PLS-линейки на выводы SPI для программирования, дальше на макетке это дело использовал. Давно забил на это и забыл как страшный сон, проще разводить макетные платы и заказывать их, благо под рукой есть производство с ценой макетного качества (две стороны, металлизация) 100 гривен ($12) за лист А4

[KMG]

Это давно не соответствует действительности. Разве что только крайний 8миногий случай, но он очень крайний.

Я имел ввиду именно сегмент 8-20 ног.
32 ног и больше конечно выгоднее использовать ARMы.

Я часто поступал так - припаивал прямо на ножки дипа кварц, кусочек PLS-линейки на выводы SPI для программирования, дальше на макетке это дело использовал. Давно забил на это и забыл как страшный сон, проще разводить макетные платы и заказывать их, благо под рукой есть производство с ценой макетного качества (две стороны, металлизация) 100 гривен ($12) за лист А4

95% форумчан используют лут и платы заказывают только когда выходят хотя бы на мелкую серийку, это то же нужно учитывать.

[Rst7]

Я имел ввиду именно сегмент 8-20 ног.

8 ног - это крайний и единственный случай. 20 - уже ARM. Хотя бы просто потому, что ATTiny2313 (20 ног) стоит аналогично ATMega48 (32 ноги) и аналогично LPC11xx (32 или 48), занимает места тинька на плате больше чем другие, а ресурсов - меньше всех. Так что вывод однозначен.

Ну а бояться QPF-корпусов - так это по нынешним временам просто стыдоба.

95% форумчан используют лут и платы заказывают только когда выходят хотя бы на мелкую серийку, это то же нужно учитывать.

Лут вполне обеспечивает технологию 0.25/0.25, что закрывает все вопросы с корпусами TQFP-32 (маленькие меги), LQFP и QNF (LPC11xx-13xx-17xx).

И вообще, учитесь у китайцев. Пятипортовый свич на односторонке:



Между прочим, с точки зрения профессионала вопросов к плате нет.

[Peratron]

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

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

[Peratron]

Кстати, для станка для экспериментов лучше тогда брать макимальный чип

В нано - максимальный чип. А именно - мега 328. то есть. старший в этой линейке (с наибольшим объёмом памяти).

Отличия между версиями дуины - исключительно в наличии/отсутствии третьестепенных прибамбасов типа гнезда питания 2.1 мм и прочих маловажных.
Нано имеет встроенный стабилизатор с возможностью его отключения - рабочий диапазон напряжений от 3.3 до 20 В.
Подчеркну ещё раз - нано с точки зрения функционала ни в чём не ущербен и имеет значительно уменьшенные габариты за счёт применения смд-компонентов вместо дипов. Ну, и гнездо усб взято мини, а не стандартное.

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

Ардуино в целом и соответствует этому критерию - изначально оно было собрано на меге 8, а в последующих версиях проц заменяется более современными клонами именно восьмерки: мега168/мега 328.
То есть, за основу взят проц из старшей атмеловской линейки, обладающий хорошим запасом по функционалу.
Потому отрабатывать на дуине софт для тиньки - это совершенно без проблем.

А вот это как раз уже не выйдет так как к порту микроконтроллера уже подключен FTDI чип и порт используется для загрузки программ. Именно этим мне не нравится ардуино.

А как это помешает использованию в автономе?!
Залил программу - причём, без разницы, через усб, сериал или через SPI. После чего без проблем пользуешь миди.
Нет проблем соорудить миди и на других выводах - но только придётся озаботиться написанием своего собственного софта.
Зато дырок хватит на десяток миди-портов...

Между прочим, стандартный выводы программирования SPI точно так же являются мультифункциональными и вне фазы программирования используются для общих целей.
Это на всех атмелах так - и никто не парится...

[Rst7]

Кстати, о макетках с матерыми корпусами. Совсем забыл про угарнейшую фотку



Внезапно ARM9 в инкарнации AT91RM9200 (корпус для начинающих - PQFP208), SDRAM (100МГц, кстати, не балуйся), линуха, в общем, все дела. Работает у автора вполне без нареканий.

А вы говорите - ой-ой-ой, без DIP'а никак не можем 

[Peratron]

Основополагающий ресурс для изучения AVR начинающими - разжёвано всё, и до безобразия.
Настоятельно рекомендую!
[size=14]
http://proavr.narod.ru/[/size]

[research]

у di:halt поинтереснее расписано все. у Николаева - тоже недурно.

Специально для Черешни http://forum.gtlab.net/cgi-bin/yabb2/YaBB.pl?num=1261262645/0

[DDD]

Мужики, это не из той ли примерно оперы, что вы тут обсуждаете?
http://www.oct-distribution.com/datasheets/SKRM-C8-G01.pdf
http://www.oct-distribution.com/datasheets/SKRM-C8-XXX.pdf
http://www.oct-distribution.com/

[KMG]

Нет, это модули на основе специализированного DSP Spin Semiconductor FV-1.
http://www.spinsemi.com/products.html
Функционально где то близкого к комплекту AL3201.
http://www.yerasov.ru/shop/product_info.php?cPath=27&products_id=201

В этой теме идет разговор о микроконтроллерах общего применения.

[Peratron]

Мужики, это не из той ли примерно оперы, что вы тут обсуждаете?
http://www.oct-distribution.com/datasheets/SKRM-C8-G01.pdf
http://www.oct-distribution.com/datasheets/SKRM-C8-XXX.pdf
http://www.oct-distribution.com/

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

Потому это тут не в теме - если речь не о продвинутом устройстве управления режимами ДСП при помощи отдельного микроконтроллера, конечно...

[KMG]

Потому это тут не в теме - если речь не о продвинутом устройстве управления режимами ДСП при помощи отдельного микроконтроллера, конечно...

По теме управления ДСП.
Загрузчик пользовательской программы в AL3201 (вместо прошитых эффектов) совместим c "Wavefront DRE Development System".
Причем загружать можно "на лету" (без пересброса дсп) хоть одну команду дсп хоть всю программу.
Может кому в копилку пригодится.
http://milas.spb.ru/~kmg/files/projects/dre/avr/Dre.c

[Peratron]

@ KMG
Давай под ДСП выделим другую тему - я понимаю, что на данном этапе тема скучна тем, кто уже владеет МК. Но не нужно её зашумливать - тема начального уровня нужна для тех, кто только присматривается к МК и пытается понять, насколько это доступно и с какой начальной точки следует во всё это погружаться.
Ы?

[KMG]

Тогда полезная книжка в оригинале и переводе.
http://milas.spb.ru/~kmg/files/literature/Kernighan_Ritchie_Language_C.pdf
http://milas.spb.ru/~kmg/files/literature/Kernighan_Ritchie_Language_C_ru.pdf

PS Женя, исходник привел как пример управляющей программы на AVRе.
С одной стороны последовательный протокол к РС (DRE Development System), с другой протокол загрузки в ДСП.
И ни слова о программировании для ДСП

[Rst7]

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

После появления ссылки на ресурсы аля-123 тему Вы свою сами зашумели по самое не могу, господин Peratron.

Может кому в копилку пригодится.
http://milas.spb.ru/~kmg/files/projects/dre/avr/Dre.c

Ну вот и наглядный пример заботливо разложенных граблей. Code Vision - это не компилятор, а УГ. При попытке собрать этот код вменяемым компилятором будет жопа. Код будет неработоспособным.

Одни из граблей кроются вот тут:

Код: [Выделить]

unsigned char      DelayCnt;
...
interrupt [TIM1_COMPA] void timer1_compa_isr(void)
{
..
      if (DelayCnt != 0)
            DelayCnt--;
...
}

...

Delay(int ValmS)
{
      DelayCnt = ValmS;
      while (DelayCnt != 0)
      {
            Wdog();
      }
}

Ну и общий стиль программирования удручает, конечно. Вместо вменяемых размеров (uint_fast8_t) регистровых переменных везде всякие

Код: [Выделить]

void
WriteArea(unsigned long* Src, unsigned char Addr, unsigned char Len)
{
       unsigned char      BitCnt;
      unsigned char      WordCnt;

Первая же процедура обработки прерывания написана совершенно без оглядки на архитектуру ядра. Внезапно RISC-ядра - они все load-store архитектуры, посему технически грамотно писать код так

Код: [Выделить]

uint8_t RxByteCnt;

// USART1 Receiver interrupt service routine
void usart1_rx_isr(void)
{
  uint_fast8_t rxc=RxByteCnt;
  ...
  if (rxc<8)
  {
     ...
     rxc++;
  }
  if (rxc==10)
  {
   ....
   rxc=11;
  }
 ....
 RxByteCnt=rxc;
}

Понятное дело, это пример с одной переменной. А их там есть.

Настоятельно рекомендую разобраться в приведенных выше примерах граблей и неоптимальностей.

[ivana]

Ваааа!... Ничего не понятно... Но красиво!  :o
Надеюсь и я когда-нибудь смогу разобраться в этих тонкостях 
ЗЫ а по поводу неоптимальности и без оглядки на структуру... Не читал ещё холиваров по этому поводу, но предполагаю что они есть. Оптимизировать можно многое, только если хватает ресурсов и работает надежно и дубово - то почему бы и не оставить? Несколько циклов в цикле, например, чем связываться с капризной рекурсией, которая может заглючить в любой момент (опять же, из-за недостаточной аккуратности написания)? А про ядро - может этот код будет таскаться по разным ядрам - зачем оптимизировать под одно? Или это стандарт?

ЗЫ хотя я сам уже лет 15 как зарабатываю на жизнь программированием в 1С (только не надо чванливо плеваться), и понимаю, как порой хочется оптимизировать чужой код, даже официальных разработчиков 

ЗЗЫ хотя вот это уже на глаза попадалось

QUOTE (scifi @ Jul 27 2011, 16:01) *
Эх, причесать бы код и абстрагировать от железа - получился бы полезный для многих проект.

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

[Rst7]

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

Среди профессионалов холиваров на эту тему нет.

чем связываться с капризной рекурсией,

Рекурсию вообще не следует использовать. Ибо это грабли еще те, причем, очень неэкономные по стеку.

А про ядро - может этот код будет таскаться по разным ядрам - зачем оптимизировать под одно? Или это стандарт?

Все современные (вменяемые) процессоры устроенны в принципе одинаково. И стиль оптимизации тоже одинаков. Тот пример оптимизации с регистрами, что я привел - он достаточно всеобъемлющий.