В статье речь пойдёт про отечественный МК фирмы Миландр 1886ВЕ5У, будет совсем немного кода и много нытья.
Данный МК построен на ядре PIC17, что заметно при разработке — так как у меня уже есть солидная кодовая база для PIC, мне было чуть проще начать. Также под данный МК можно приобрести отладочную плату — о ней я тоже пару слов напишу.
Я расскажу с какими проблемами столкнулся при разработке прошивки, что понравилось, а что не очень. Всё написанное — моё личное субъективное мнение, потому, сразу оговорюсь, возможно будут описаны проблемы, которые и не проблемы вовсе, а совсем даже особенности и которых можно было бы избежать, обладай я большим опытом разработки.
Итак, поехали.
Первое, с чем в 2017-м году столкнётся желающий использовать в своих разработках МК от Миландра — это сложности с покупкой. Даже не говоря о цене, вам для этого скорее всего потребуется как минимум какое-нибудь юр.лицо. По крайней мере, когда я звонил им в отдел маркетинга и узнавал о покупке как физ.лицо, мне ясно дали понять, что в этом случае мне проще будет найти какого-нибудь поставщика (цены у которых ещё выше). В общем, с маркетингом всё печально. С другой стороны, сайт они вон уже обновили, может и до маркетинговой политики руки дойдут как-нибудь.
Корявая документация
Несмотря на то что 1886ВЕ5У вышел уже лет пять назад минимум, «детские болезни» никуда не делись. При чтении тех.документации создаётся ощущение, что делали её наспех. Нет, критически важная информация там, в принципе, присутствует, только вот структурирована она достаточно странно. В тексте периодически встречаются опечатки, да и сама структура документа, на мой взгляд, не блещет логичностью. В итоге при разработке вместо изучения одного единого документа периодически приходится метаться между несколькими открытыми окнами или искать нужные в текущий момент фрагменты в основном даташите, которые могут располагаться в документе достаточно далеко друг от друга, даже если относятся к одному блоку чипа.
Ещё например, странно, что руководство по прошивке чипа вынесено в отдельный документ. Может это и удобно в каких-то случаях, но почему бы не сделать отдельную главу или приложение к основному даташиту?
В качестве иллюстрации приведу один пример. Для расчёта скорости CAN-интерфейса нам предлагают воспользоваться несколькими формулами.
При расчёте получается, что итоговая формула, фактически, будет иметь пять параметров (
BRP, PRSEG, SEG1, SEG2, Fosc). Сама формула и зависимость параметров от значений бит в регистрах разнесены страниц на пятнадцать. В итоге, проще сделать скрин с таблицей значений регистров и открывать его в пэинте, пока разбираешься с формулой.Вообще, даже сам подход с формулами это тот ещё изварт. Чёткая формула это, конечно, прекрасно, но каждый раз пересчитывать значения в уме или на бумажке это то ещё удовольствие. Я, например, в итоге, запилил формулу в Mathcad и считал уже в нём.
Вопрос к составителям документации — собственно, а в чём проблема была добавить всего пару страниц с таблицами, содержащими базовые значения при нескольких значениях параметров? За примером далеко ходить не надо — даже в документации на PIC такие таблицы есть, например, в разделах про настройку скорости UART.
Кстати, отдельно хочется отметить интересный момент, возможно, кому-то будет полезно на будущее. Я не отношу себя к знатокам CAN-интерфейса, вполне возможно, что это справедливо для любых устройств CAN, а не только в этом конкретном случае. Также, возможно, это особенность унаследована от PIC17, хотя я сходу не смог найти PIC17 с CAN интерфейсом.
В общем, если у нас есть два устройства на 1886ВЕ5У, одно из которых работает на 16 МГц (отладочная плата, например), а второе на 10 МГц (наша железка), то связать их, скорее всего, получится только на низкой скорости, и то не факт. И вот почему.
Во первых — максимальная скорость (для железки работающей на 10 МГц) при всех выключенных делителях ограничена 390.6 кБит/с.
Во вторых — при 10 МГц дискретность изменения такова, что получить, например, стандартные 250, 125 или 100 кБит/с никак не получится. По расчётам самое близкое получается, например 104.2 кБит/с (
BRP=1, PRSEG=1, SEG1=5, SEG2=5). В общем, ошибка в несколько % так или иначе будет присутствовать. Я уже писал выше — пока ещё я не дофига спец в данном протоколе, возможно он и с такой ошибкой заработает на низких скоростях — в конце концов у данной шины весьма большой запас по надёжности передачи данных.В итоге быстрее оказалось поменять на своей плате резонатор на 16 МГц. Так или иначе, возможности проверить работу на низких скоростях у меня не было, а почему — я расскажу в следующем пункте.
Невозможность редактировать исходный код прошивки для отладочной платы
Вообще вся «демо-программа» для работы с отладочной платой на PC (называется она, почему-то, Eval12.exe) достаточно убогая. Из настроек там буквально только параметры COM-порта, через который вы будете с платой связываться и всё. Ну то есть, вообще всё. Скорость CAN изменить через неё никак нельзя. Изменять параметры МК, установленного в отладочную плату тоже нельзя, хотя это бывает весьма кстати.
Когда я столкнулся с разностью физических скоростей CAN и просчитал все возможные варианты по формуле, то понял, что для отладки придётся менять код отладочной платы, потому что задать скорость работы CAN-модуля в текущем варианте можно только в исходниках при компиляции.
Далее я взял исходники из папки Demo_CAN, которая шла на диске с отладочной платой, надеясь просто перекомпилировать их, задав необходимые BRP, PRSEG, SEG1, SEG2. При попытке компиляции данного проекта IDE выдала прекрасную ошибку:
"Программа защищена. По вопросам приобретения обратитесь в компанию МИЛАНДР."Я не стал разбираться в механзимах защиты — очевидно, что можно использовать какие-то куски кода из демонстрационной программы и написать свою, но сам факт, что я не могу вот так просто править код демо-программы для отладочной платы лично меня очень удивляет, это же абсурд.
Бардак в заголовочных файлах
С диска, который шёл с отладочной платой я забрал папку "komplekt_1886BE5\Демо программы".
Там лежали отдельные папки с исходниками примеров работы с CAN и LIN.
При этом в main.c этих исходников были включён следующий хедер:
#include <mil1886BE5_1.h>Собственно, в тех примерах, где он включался, данный хедер лежал в папке с примерами.
Далее, последовав совету тех.поддержки (пользуясь случаем, хочу поблагодарить сих достойнейших граждан за терпение и профессионализм — помогли мне решить пару тупых вопросов) я скачал с сайта Миландра IDE (Dev-C++ какой-то древней версии) и компилятор (CC7A).
Каково же было моё удивление, когда IDE отказалась собирать мой исходник с указанным выше хедером. Далее выяснилось, что с компилятором под мой чип идёт свой хедер — 1886VE5.h
Чтобы использовать куски кода из исходников демо-платы пришлось ещё потратить время, заменяя имена регистров на значения из нового хедера. После чего мне удалось-таки собрать свою программу с частями из демо-примеров, которая работала так, как я от неё ожидал.
Наверное на диск каким-то образом попали примеры для тестовых образцов, нормально это или нет, решайте сами. В тех.поддержке на этот вопрос вообще только лишь удивились — дескать у меня этих заголовочных файлов вообще быть не должно.
В общем-то проблема не критичная, но осадочек, как говорится, остался.
Среда, компилятор и их, кхм… особенности
В качестве среды и компилятора для 1886ВЕ5У Миландр предлагает нам использовать связку IDE1886 (на базе Dev-C++) и CC7A. В общем-то про среду ничего особо плохого сказать не могу — с программатором работает нормально, отладчик тоже вроде сносно отлаживает, разве что подсветка синтаксиса печальная, конечно. Наверняка есть какие-нибудь плагины или ещё что-то, но по дефолту это прям чуть ли не Виндовый блокнот — выделяет камменты, инклюды и некоторые ключевые слова, на этом бонусы редактора заканчиваются.
Из небольших косяков UX — моего опыта так и не хватило чтобы разобраться как же мне добавлять нужный мне регистр в наблюдаемые. По имени переменной и адресу (как описано в руководстве) IDE их не добавляет почему-то. Странно, что IDE сама не может отобразить все доступные для наблюдения регистры.
Ещё один момент, конечно, скорее говорит о моём малом опыте разработчика, но каково же было моё удивление, когда я, после нескольких часов ковыряния в отладчике и попытках разобраться почему же генерируемый компилятором ассемблерный код работает так странно, прочёл в документации, что тип
int по умолчанию у данного компилятора имеет размер 8 бит, а не 16, как принято в том же XC8 для PIC.Поэтому скажу банальность, но всё же — внимательней изучайте документацию перед разработкой =)
Следующая особенность компилятора меня вообще ввела в ступор на некоторое время. Вполне возможно, тут я очередной раз продемонстрирую свою низкую компетенцию — может быть дело в том, что этот компилятор просто заточен под какой-нибудь старый стандарт Си года 90-ого, когда это было нормой, а я просто этого не знаю, или что-то вроде того. В общем, дабы не быть голословным, приведу немного кода, надеюсь сообщество рассудит.
Компилятор совершенно не способен переварить вот такую несложную конструкцию:
TXSTA1 = ((CSRC & 0x01) << 7) | ((TX9 & 0x01) << 6) |((TXEN & 0x01) << 5) |((SYNC & 0x01) << 4);
На это он просто выдаёт сакраментальное:
"Unable to generate code."Чтобы он понял чего я от него хочу, приходится расписывать это на банальный и объёмный код:
temp0 = ((CSRC & 0x01) << 7);
temp1 = ((TX9 & 0x01) << 6);
temp2 = ((TXEN & 0x01) << 5);
temp3 = ((SYNC & 0x01) << 4);
По всей видимости, у него просто есть некий уровень вложенности скобок, глубже которого он даже не пытается распарсить код и вываливается с ошибкой.
Нет, ну серьёзно, я понимаю, что функционал компилятора видимо обусловлен его ценой, но уж в 2017-м году можно было бы уже как-то научить его это разбирать.
Напоследок
Есть ещё один момент, вероятно, связанный с архитектурой ядра. В описании к 1886ВЕ5У на сайте Миландра можно найти упоминание, что он построен на ядре PIC17. Я так понимаю, что данная особенность, свойственна всем контроллерам на ядре PIC17 — при возникновении прерывания, они не сохраняют состояние регистров, соответственно, этот момент надо реализовывать программно при необходимости. Вот это меня, честно говоря, тоже поразило — неужели в 1886ВЕ5У никак нельзя было реализовать это аппаратно?
Вообще, попробовав писать под данный МК я был вынужден ковыряться в ассемблерном коде, разбираться что это там за циферки меняются в окне «RAM» во время отладки и прочее. Это, безусловно, повысило мою квалификацию как разработчика, поскольку я чуть лучше стал понимать что там внутри и как работает. Однако, после того же Microchip'а (который частенько ругают за «безумную» Errata), кодинг под «наш» МК ощущается прям как программирование под какой-нибудь 386-й в DOS. Кстати, по поводу Errata — к данному МК вообще ничего типа Errata нет.
Ни сколько не умаляю достоинство наших разработчиков из Миландра — сама железка вроде бы вполне исправно завелась у меня и работает, но вот поддержка ПО и среды разработки выглядит так, будто делают всё наспех. Возвращаясь к вопросу, поднятому в заголовке — сравнение IDE1886 с тем же MPLAB пока отнюдь не в пользу первой. Единственный плюс IDE1886 это компактность и возможность работать без установки, но не думаю, что это такие уж критичные моменты.
Очень надеюсь, что за ближайшие несколько лет разработчикам удастся подтянуть этот показатель к уровню ведущих брендов.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (88)
nerudo
07.06.2017 07:38+5У того же TI адский ад в документах (хотя формально они есть и весьма толстые), хотя там их пилят куда как больше народу. А тут два инженера для пяти покупателей из которых четыре — в погонах…
BelerafonL
07.06.2017 12:52У TI ещё очень хорошо всё с документацией по сравнению с некоторыми. Может быть, конечно, разные изделия по-разному описаны, но документация микроконтроллеров ядра C28 на мой взгляд и взгляд моих коллег просто образцовая.
Dima_Sharihin
07.06.2017 07:55+4Отсутствие автоматического сохранения контекста при переходе в прерывание — это вообще довольно стандартная особенность микроконтроллерных ядер, особенно, если важна максимально быстрая реакция на внешнее событие.
Просто часто среда разработки дописывает этот код за программиста в зависимости от непосредственно кода обработчика прерывания.
Вот это меня, честно говоря, тоже поразило — неужели в 1886ВЕ5У никак нельзя было реализовать это аппаратно?
Уж лучше везде будет одинаково, чем программисту придется писать разный код для одной и той же архитектуры процессора.
Psychosynthesis
07.06.2017 08:11Просто часто среда разработки дописывает этот код за программиста в зависимости от непосредственно кода обработчика прерывания.
В общем-то не важно как это происходит, главное что это можно было бы реализовать, причём нечего особо сложного в этом нет.
Уж лучше везде будет одинаково, чем программисту придется писать разный код для одной и той же архитектуры процессора.
Код так или иначе править под конкретную платформу придётся — компиляторы-то разные. Считаю что приемлемый уровень совместимости платформ вполне достигнут. Фишка про сохранение контекста — скорее из разряда хотелок.
Jef239
07.06.2017 09:23Ну обычно пишут под конкретную RTOS и оформление прерываний задается операционной системой. Например, FreeRTOS имеет порт на PIC.
Кстати, этот момент вы не раскрыли совсем — какие RTOS работают на этом кристалле?aquamakc
07.06.2017 09:27+2Операционка — всего лишь инструмент, который позволяет некоторые задачи решать более удобным способом, но совсем не обязательный к применению. Посему корить автора за то, что этот момент был обойдён не корректно.
Jef239
07.06.2017 09:47+1От задачи зависит. Зачастую ОС — это 90% бинарного кода прошивки. То есть сама прикладная логика — очень простая (или уже написана для иного процессора). Если стоит задача выбрать российский процессор взамен импортного, то лучше уж выбирать такой, на котором работает известная тебе ОС.
А если импортозамещение не стоит, то лучше уж процессор с большим тиражом и большим количеством пользователей. То есть что-то популярное западное. А не российская мелкотиражка, которая в любой момент может исчезнуть из продажи.aquamakc
07.06.2017 10:02+1Готов подписаться под каждым предложением, кроме второго. Если ОС — 90% кода, может проще обойтись без неё? Особенно, если камень «маленький».
Jef239
08.06.2017 00:5790% кода означает, что нам нужны очереди, треды, таймерное прерывание, контроль размеров стека, watchdog, bootloader, отладочная консоль и все прочее, что обеспечивает RTOS и библиотеки. А код самой задачи — довольно мал по сравнению с тем, что дает RTOS.
Как пример — мультиплексор на 4 канала. Сам код мультиплексора — 3 странички. Остальное — готовое из ОС и библиотек.
P.S. Для меня «без ОС» — это переход с linux на FreeRTOS. :-)
Psychosynthesis
07.06.2017 12:59Увы, я не запускал на нём RTOS — задачи таковы, что нужно максимальное быстродействие, лишних ресурсов нет.
Vcoderlab
07.06.2017 20:20+3Какие RTOS, что вы.
Память программ 4096 команд, ОЗУ 902 байт. Сюда и без RTOS влезть бы…
TRYFAN
07.06.2017 12:52На PIC регистры сохранить 8-10 команд и не используйте общие регистры в прерывании
Jef239
07.06.2017 09:18+9Когда мне было лет на 30 меньше, чем сейчас, подхожу я к шефу — в документации на процессор вот такая-то деталь не описана. Шеф показывает — 232 страница, фраза внизу — читай! Теперь 104ая фраза вверху — читай, теперь 305ая, фраза в середине — читай. а теперь сложи все вместе. Видишь, все описано!
Любую плоскую (plain text) документацию сложно написать так, чтобы для любой задачи она читалась последовательно, а не выборкой разных кусков. Чтобы было удобно — надо или делать гипертекстовую документацию или в дополнение к описанию процессора писать толстенный user guide с описанием типовых задач.
Увы, на большинство микропроцессоров нет ни того, ни другого. Так что привыкайте, на других процессорах легче не будет.Psychosynthesis
07.06.2017 15:07+4Частично я с вами соглашусь — сложная система практически не может быть строго линейно документирована. Но общий уровень документации у наших МК всё же ниже чем у зарубежных.
За примером далеко ходить не надо — например, что мешало добавить в нашей спецификации таблицу со всеми регистрами и их стартовыми значениями? Для PIC'ов такая почти у всех чипов есть. У нашего же я вообще не знаю точно сколько же у него всего регистров, разве что самому перечитать весь документ.
И да, на других процессорах всё-таки пока легче. Я уж молчу про всякие ардуины и прочее…
burjui
07.06.2017 15:27+2Любую плоскую (plain text) документацию сложно написать так, чтобы для любой задачи она читалась последовательно, а не выборкой разных кусков.
На STM32 как-то умудряются писать нормальные даташиты в PDF.
aquamakc
07.06.2017 15:34) тоже не эталон.
Чтобы что-то писать на STM надо держать открытыми целую кучу документов: Datasheet, Generic User Guide, Programming manual, Reference manual, Standard Peripheral Library, User manual.Psychosynthesis
07.06.2017 15:38Reference manual достаточно изучить один раз и запомнить — базовые принципы редко меняются.
aquamakc
07.06.2017 15:40+2) вы меня простите, но я — человек, мне тяжело запомнить почти полторы тысячи листов текста на неродном для себя языке.
Psychosynthesis
07.06.2017 16:21+1Видимо мы про разные документы говорим. Если вы про их аналог даташита где перефирия описывается, то, опять же, запоминать все «полторы тысячи листов» вовсе не обязательно по понятным причинам.
Так или иначе, минимум половина из перечисленного вами в постоянно открытом виде точно не нужна — вы притягиваете за уши. Взять хоть тот же user manual — уж отладочная-то плата у вас от проекта к проекту редко меняется, да и в UM вообще ценного не много обычно, распиновки разве что.
rrrav
08.06.2017 17:54К тому же они выкатывают такой хороший инструмент — CubeMX — что все сложное становится простым.
Johnli2017
07.06.2017 12:52-5Первое, с чем в 2017-м году столкнётся желающий использовать в своих разработках МК от Миландра — это сложности с покупкой. Даже не говоря о цене, вам для этого скорее всего потребуется как минимум какое-нибудь юр.лицо..
Двоякое чувство…
У автора, видимо не возникает проблем с покупкой оруж_я и наpкоtиков, а вот для покупки продукции с приемкой «ВП» попросили юр.лицо, вот засада… Еще должна быть специфичная лицензия или печать особая на заявке — к сведению.
При обращении называют все: цена, срок поставки + при необходимости поставляют бесплатные образцы, по запросу…
А, еще сказали что микросхема звучит 1886ВЕ5БУ или К1886ВЕ5БУ, интересно, что купил автор и у кого?
Про демо-версию вообще странный вопрос…Psychosynthesis
07.06.2017 12:57+2Разговор шёл про версию без ВП. Нашу версию, которая с пятой приёмкой, покупали через институт.
Ну и по поводу индекса «К» — это справедливо для советских микросхем. В данном случае, военная приёмка или нет, микросхема называется одинаково, без индекса, разница только в отметке ОТК, ну или в корпусе, если речь идёт про другие модели контроллеров.
Про бесплатные образцы, согласен, предоставить могут, но не абы кому. Васе «с улицы» никто подобные образцы не даст. Учебным заведениям — пожалуйста. Собственно, вопросы к маркетингу остаются.Mikeware
07.06.2017 13:16+1отсюда простой вывод: контора не заинтересована в сбыте, а следовательно — в выпуске продукции. поэтому контроллер всегда будет низкотиражным и «золотым». поэтому коммерческую продукцию на нем разрабатывать нельзя. ну и круг замыкается :-(
aquamakc
07.06.2017 13:30Военные, у которых вариантов других просто нет будут покупать независимо от качества и молчать в тряпочку. Гражданские начнут сравнивать и ныть (справедливо), что продукция мягко-говоря не айс. Зарубежные аналоги дешевле, технологичней и имеют лучшее сопровождение. По-этому для прессы отчитались о выполнении программы «импортозамещения», особо рьяным энтузиастам (юридическим) пару десятков кристалов поставили и забыли. Деньги всё-равно идут за счёт оборонзаказа.
Mikeware
07.06.2017 13:35+2«за счет оборонзаказа» — это «за счет бюджета».
Ну и как в советские времена, нормальной гражданской экономике остаются объедки.
чем это закончилось — напоминать не буду… :-(aquamakc
07.06.2017 13:37нормальной гражданской экономике остаются объедки
Не знаю плохо это или хорошо, но есть небольшое отличие — пока ещё можно приобретать электронку за рубежом.Mikeware
07.06.2017 13:41+2так обидно же! потребности есть. теоретически — есть продукция. казалось бы, выпуска, насыщай, замещай — за счет этого удешевляйся и конкурируй (пусть даже запретами и прочими непопулярными методами, но все же)
как говаривал кот матроскин в мультике:«средства у нас есть. у нас ума не хватает»©aquamakc
07.06.2017 13:48На самом деле «догнать и перегнать» врядли получится. По крайней мере на поле типовых решений. Всё «импортозамещение» заключается в лицензировании ядра, закупке оборудования для производства и запуске поставленной линии. Причём пока эти этапы проходят основные западные производители успевают сделать пару итераций обновления линейки и оптимизации производства.
В результате «отечественные разработчики» «конкурируют» с западными имея на руках устаревшие технологии, производственную линию и крайне скудное понимание как оно там внутри работает. При этом гражданский рынок почему-то (сарказм) отказывается приобретать продукцию в 3-4 раза дороже забугорного аналога. И как-следствие, энтузиазм развивать что-либо под свободный рынок даже если и был просто улетучивается.Barafu
07.06.2017 14:19+1Существует старинный, родом из средней Азии, способ всегда побеждать в соревнованиях. Заключается он в том, чтобы не вступать в те соревнования, где ты можешь не победить. У нас устаревшие линии и технологии? Ну и хорошо, значит можно делать простой, понятный чип с хорошей документацией. Не блещущий характеристиками, но достаточный для многих применений. Пусть он кушает энергию, зато у него не едет крыша если питание просело на 2%. Пусть он многое не умеет, зато цена разработки под него маленькая, особенно стартовая цена. А то у некоторых чипов стартап не потянет закупку не самого чипа, а компилятора и документации по нему. Можно делать то, что лидеры рынка никогда не делают: давать гарантии, что в течении Н лет данная модель с продажи не исчезнет. Для кого-то это будет очень весомый плюс.
Вот тогда и клиент найдётся. И не надо при этом иметь доступ к лучшему в мире нанометру. Но жаловаться-то проще.aquamakc
07.06.2017 14:26Так я же не против приведённого вами сценария. Но ведь пошли то по другому пути. Заведомо проигрышному в нашей ситуации.
По факту имеем более дорогой, менее технологичный контроллер с ужасным документированием, отсутствием «родной IDE», слабой поддержкой и т.д.
Mikeware
07.06.2017 14:30причем этим можно перекрыть огромный сектор спектра потребностей. Все эти ККМ с онлайнами, эроглонассы, платонотерминалы имени роттенберга, изрядная доля мелкого коммутационного оборудования, кишки для микроволновок…
hardegor
10.06.2017 10:23Заключается он в том, чтобы не вступать в те соревнования, где ты можешь не победить.
Если не вступать в соревнования, то как понять, правильным ли путем идешь? Ведь именно встреча с сильным противником позволяет понять сильный он или нет.
А может быть вообще ничего не делать, тогда и в соревнования вступать не придется :)
Jef239
08.06.2017 00:35На самом деле российский fabless работает примерно в тех же условиях, что и американский. То же производство на TMSC, например. В итоге получаются, вполне неплохие продукты, например GNSS-приемник GEOS-3MR как «российский ublox».
В среднем — паритет. У нас на пару долларов дороже, зато фаза чище. Но… есть одно преимущество. Работая с российским приемником, я могу связаться с авторами и сказать «коллеги, вот тут у вас в прошивке, похоже, бага». И получить и ответ и исправление прошивки. А вот с западными — так не получается. Причем это верно для не только для авторов Geos-3, с другими российскими разработчиками приемников — ровно то же самое.
И это перевешивает разницу в пару долларов по цене.aquamakc
08.06.2017 11:39+1Про трекеры ничего сказать не могу, ибо не в теме. С контроллерами сталкиваюсь, потому имею некое представление и могу сравнивать.
Я не спорю, что какие-то «нишевые» продукты мы можем и делаем достаточно неплохо. Есть, например, Multiclet. Но вот покажите мне человека, который их реально использовал не в оборонке? Проблема именно с массовыми продуктами.Jef239
08.06.2017 13:47Про трекеры тоже сказать ничего не могу, GPS-приемник — это далеко не трекер. :-)
Мы их используем не в оборонке, но тоже продукты не массовые. Например — спутниковые компасы. В массовый сегмент мы тоже хотим, но все осложняется тем, что в РФ нету массового сегмента крупных яхт. Так что массовый сегмент — это ориентация на Калифорнию.
В целом, кроме оборонки, есть достаточно большой сегмент гражданки, приближенный по требованиям к оборонке. Например — транспорт, энергетика и так далее. И там бывает, что российское железо — не хуже или лучше.
А ширпотреб… ширпотреб везде китайский.
Jef239
08.06.2017 14:32А в массовом сегменте только К1879ХБ1Я знаю. Но это как раз массовый сегмент — декодеры для всяких триколор-ТВ.
buratino
14.06.2017 09:40На самом деле «догнать и перегнать» врядли получится
для этого надо, чтобы было кому догонять, чтобы догоняющий был хотя бы обут в кроссовки, а не в кирзу или босиком. Еще догоняющий должен видеть на горизонте уходящий поезд и бежать за ним, а не в сторону или назад. Ну и шпалы с рельсами не надо разбирать. :-(
Johnli2017
08.06.2017 16:38Про бесплатные образцы, согласен, предоставить могут, но не абы кому. Васе «с улицы» никто подобные образцы не даст. Учебным заведениям — пожалуйста. Собственно, вопросы к маркетингу остаются.
Думаю, что никто из присутствующих, не раздает результаты своего труда Васе с улице, коим, вероятно вы и представились. Если есть вопросы к маркетингу — скажите с кем общались или задайте здесь… Образцы там получить совсем не сложно для любого предприятия РФ, конечно, в обмен на отчет об использовании, что бы сделать их лучше для нас.Psychosynthesis
08.06.2017 21:32Ну, вопросы к маркетингу есть скорее общие, причём не у меня одного — тут на эту тему уже не один десяток камментов появился, как видите.
С кем общался сейчас уже не скажу — это было больше года назад уже.
Образцы там получить совсем не сложно для любого предприятия РФ, конечно, в обмен на отчет об использовании
Не могу утверждать обратного, конечно. Возможно, когда будет время попробую позвонить и поговорить на эту тему в ваш отдел продаж.
Nednik
07.06.2017 13:52Не понимаю в чем критичность проблемы.
Как и на любой другой процессор нужно очень тщательно читать документацию, у меня проблем не возникло проблем с использованием К1986ВЕ92QI. На новом сайте документацию неплохо переработали.
За сохранение регистров в стек и извлечение оттуда, если использовать С и какой нибудь IAR, я вообще ни разу не беспокоился. На ассемблере это в любом случае должен делать сам программист.
По поводу получения цен, прямо на сайте есть:
Тут
тут
точно не в 4 раза дороже процессора с CORTEX M3,M4FPsychosynthesis
07.06.2017 13:54Я нигде не писал что есть какие-то критичные проблемы. Я писал, что не дотягивает до уровня «как у них», и только.
Новый сайт вообще в целом поприятней, соглашусь.
aquamakc
07.06.2017 14:08Окей, давайте сравним К1986ВЕ92QI и STM32F205RET6
Цена: 715 и 380 р. — почти в 2 раза
Частота: 144 и 120 MAX — тут всё хорошо, захочешь — не придерешься
FLASH: 128 K и 1 M — а вот тут тяжело не закручиниться
ОЗУ: 48 К и 128 К — продолжаем тяжело вздыхать
АЦП: 1 и 3
I/O Ports: 96 и 140
ну и т.д.
Информация взята из официальных даташитов.Nednik
07.06.2017 14:17По поводу АЦП несколько ошибаетесь, их 2 в указанном процессоре, остальное не проверяю.
FLASH: 128 K и 1 M — а вот тут тяжело не закручиниться — не представляю для чего)
И согласитесь не 3-4 раза ;)aquamakc
07.06.2017 14:21И согласитесь не 3-4 раза
Ну так это и не аналоги ). Если мы найдём на рынке полный аналог с соответствующими параметрами и посмотрим цену, разница будет явно больше, чем в приведённом примере.
FLASH: 128 K и 1 M — а вот тут тяжело не закручиниться — не представляю для чего)
Если у нас не очередная «погодная станция», то 128 К под прошивку — крайне мало.
По поводу АЦП несколько ошибаетесь, их 2 в указанном процессоре
Я, если честно, не вчитывался особо, но вот цитата из даташита:
Аналоговые модули:
— 12-разрядный АЦП (до 8 каналов) с амплитудой измеряемых сигналов 0?3,6 В;Nednik
07.06.2017 14:22Указан был К1986ВЕ92QI — в нем 2 ацп.
aquamakc
07.06.2017 14:32Указан был К1986ВЕ92QI — в нем 2 ацп
я поправился позже
Прошу прощения, не К1986ВЕ92QI, а К1986ВЕ1QI
92 стоит чуть больше 400 р, но он и слабее: тактовая до 80 МГц, ОЗУ 32, нет Ethernet, по одному UART, I2C и SPI… ну и т.д.
Сравнивать его с STM32F205 вообще нельзя.
Nednik
07.06.2017 14:21Соглашусь что действительно отечественные процессоры уступают на данный момент зарубежным в данном сегменте, но ситуация все же лучше чем 2-3 года назад.
svitoglad
07.06.2017 15:01+1Почти на 15 лет назад вернулся. С КР1878ВЕ1 было то самое: трудно достать, корявая документация, капризная среда разработки, «глюки» самого чипа. :)
http://www.microchip.ru/phorum/read.php?f=2&i=4685&t=4685
Arbane
07.06.2017 17:50Мне статья понравилась, только вопрос — а зачем этот микроконтроллер вообще нужен? Если военка и заказные разрабоки от государства, то, наверное, Миландр тоже делает военным или разработка заказная (под бюджетные деньги), тогда она никогда и никуда не вырастит.
Если проект другой, то можно обойтись без этого чуда. Да даже в указанных мною областях обходятся без наших деталей, потом находишь регулярно китайский чип с нашей маркировкой. Зачем разработка, зачем этот труд, если разработчику «не интересно»?
Выше уже поднималась проблема отставания, где я согласен, нужно взять качеством и сервисом.
Пока читал, сложилось впечатление, что там студенты практику проходили. Кто-то из Миландра есть на Хабре?Psychosynthesis
07.06.2017 18:08Ну, я надеюсь, нужен он в качестве своеобразного «старта» и начальной продуктовой базы, как и некоторые другие модели МК от данного производителя.
andi123
07.06.2017 17:50Один из последних проектов делал на связке 1886ве6 и ве7. Все тот же PIC17.
Прошел через все те же грабли, что и автор и не согласен почти ни с чем. Точней все эти проблемы имеют место быть, но в сложившихся условиях именно так и должно быть. Документация с ошибками, нулевой маркетинг и смешной CC7A. И любые попытки это исправить приведет к тому что Миландра просто не будет.
Начнем с того, что все эти изделия были разработаны (я имею ввиду ядро) во времена когда МК были «большими и ламповыми». Требовать от них тонкой подстройки скорости последовательных интерфейсов глупо. Я понимаю, что xmega (где я впервые увидел возможность сделать дробный коэф. деления) и stm32 это круто, но они лет на десять моложе.
Теперь про бедный CC7A. Судя по всем признакам разрабатывался он суровыми норвегами в начале 2000-х. С тех пор он том же уровне и остался. Ничего кроме PIC17 он не поддерживает. А сам PIC17 уже давно днем с огнем не сыщешь.
Тоже самое про весь Миландр в целом. Сравните бюджеты Миландра и какой нибудь ST. Кормовая база не та, чтобы по $10 и бесплатно раздавать направо и налево отладки.Psychosynthesis
07.06.2017 18:03Вы абсолютно правы, про все эти аргументы я думал.
Конечно, напрямую сравнивать Миландр с гигантами индустрии глупо. Мне всё это вполне понятно. Я вообще считаю, что сам факт наличия этих железок при текущей ситуации с промышленностью, это достижение. Но, с другой стороны ведь и объёмы у них другие. И совковый подход к маркетингу это никак не оправдывает. Соответственно подход должен быть другим. Возможно буду банальным, но приведу в пример Apple, которая в своё время «въехала» на рынок с тремя продуктами, сделав упор на их качество и грамотный маркетинг.
Всё же, хочу обратить ваше внимание — я не поливаю грязью нашу промышленность, я лишь описал особенности, поскольку информации по теме в сети практически нету. Мне казалось что такие статьи должны быть полезны.andi123
07.06.2017 18:37А я как раз хочу сказать, что пример Apple тут совершенно неуместен и вреден (если что, въезжала она на пустой рынок персоналок). Никакой грамотный маркетинг не позволит отжать (у TI, NXP, ST не говоря про всех китайцев, я даже тут про самсунг не говорю) такую долю рынка чтобы из него валились красивые доки и дешевые отладки.
А рынок в России ограничен самым серьезным образом. Мы не делаем ширпотреб на весь мир. Только узкоспециализированные решения для конкретных отраслей.
saw_tooth
07.06.2017 18:13+1А никто не говорит налево и направо.
ST сделали отличный пиар-ход, раздавая дев-борды на халяву, и вот результат: за 5 лет, очень много людей начали ее использовать, в коммерческих и не очень целях.
Но здесь, потраченные тысячи сделали неоценимую услугу ST, это и развитие опен сорса, и допиливание самих контроллеров, и мнение комьюнити по развитию и многое другое.
А Миландру, если уж все так плохо, к лицу было хотя бы давать по сходной цене, но одному МК в руки по ФИО физ лицам. Уверен, это не такие огромные затраты, зато очень ценную обратную связь можно получить, хотя бы применить данную стратегию к известным целевым компаниям-разработчикам… так сказать дать для проявления какого либо интереса к своему продукту.
А так он мало кому будет интересен и не будет расти, в плане специалистов и в плане своего софта.andi123
07.06.2017 18:45+1Уверен, это не такие огромные затраты, зато очень ценную обратную связь можно получить, хотя бы применить данную стратегию к известным целевым компаниям-разработчикам… так сказать дать для проявления какого либо интереса к своему продукту.
Почитай-те что ли тут подборку статей про микроэлектронику от BarsMonster.
svitoglad
07.06.2017 22:18До ST дев-борды другие производители тоже на халяву раздавали но у них так не получилось. Просто ST предложила недорогие чипы в эпоху перехода на более производительные микроконтроллеры и на фоне проблем с AVR.
vertolet0
07.06.2017 18:05Ну что они ориентируются в основном на военку это всем сразу ясно. У нас больше правда работают с 1887ВЕ4У что совместимый с Atmega 8535 AVR больше по вкусу:) Вроде и отличий особых с ним не было, работали как с AVR правда прогу программатор они свой придумали, удобная штука. А с удобством документации это, по-моему, везде импорт выигрывает. Может стандарты наши мешают или так исторически сложилось.
ProstoTyoma
07.06.2017 18:08+2CAN настраивается подобным образом везде, где я видел. Там же не только правильную скорость надо получить, но и Sampling point в нужном месте. В итоге таблица для разных частот ядра, скоростей работы, sampling point получится довольно большой.
Подробнее можно посмотреть тут: http://www.oertel-halle.de/files/cia99paper.pdf
MerQcio
07.06.2017 22:48-1Все так ругают Миландр… Почему-то никто не говорит, что PIC17 — мертворождённая архитектура разработки ну совсем не Миландра (я так думаю, поэтому её было очень дёшево купить и поэтому её купили, это было сильно ДО импортозамещения и хоть какого-то обеспечения ОПК). Почему-то никто не говорит: «А когда Вы выбирали программно-аппаратные средства для разработки, чем Вы руководствовались? Вы прочитали документацию на камень, на среду разработки, почитали ветку форума на том же Миландре, отзывы и errat'у? Вы действовали как инженер?». Вы же сами, сами его выбрали…
Когда-то разрабатывал девайс (как раз на оборонку) на 1886ВЕ1, кажется. Только потому, что на тот момент не было другого с USB. По нему и освоил USB. Никогда до того не работал с PIC. И, слава богу, больше не собираюсь. Архитектура ужасна (после AVR, молчу про кортекс). Компилятор ужасен. Среда ужасна. Но это не помешало сделать работу. Просто заранее были известны косяки, с которыми придётся столкнуться.
Берите миландровские кортексы, они прекрасны. Ещё и куча блоков вроде как собственной разработки.
Про «крохи для нормальной гражданской экономики» — в 90-х такая была, нормально было? Если кто не в курсе, стране грозит война. При ограниченном ресурсе стоит расставить приоритеты в такой ситуации — оборонка или гражданка.
И вообще, это большевики могли за 20 лет из отсталой аграрной страны, пережившей гражданскую и мировую войны, сделать первую-вторую страну мира, а у нас нынче феодально-капиталистический строй. Радоваться надо, что вообще электроника есть).Psychosynthesis
07.06.2017 22:49+1Вы же сами, сами его выбрали…
Отнюдь. Мы подрядчик, работаем строго по ТЗ. Выбирал не я. Для своих плат, я вообще настолько дорогие чипы не могу использовать по понятным причинам.MerQcio
07.06.2017 23:08В ТЗ прописан конкретный МК? А зачем? Честно, не было ни одного ТЗ, в котором был бы прописан тип МК… И вообще, его наличие)).
Psychosynthesis
07.06.2017 23:14Не конкретный, был прописан производитель. Причину я не знаю.
По факту, так как в условиях была ещё поддержка CAN, это приводит к выбору между Cortex и аналогом PIC. Кортекс, во первых, сильно избыточный для этой задачи, во вторых я его практически не знаю. Потому был выбран 1886ВЕ5У.
Что касается ТЗ… Ну, всякие ТЗ в оборонке бывают. Когда я только начинал работать инженером, мы работали над проектом, в ТЗ которого был не только конкретный чип прописан, но также например прописаны требования ко всем компонентам, от резисторов до проводов и разъёмов, и прописаны все типы интерфейсов. Причём это касалось даже тех компонентов, которые наружу никак не выходили.
vvzvlad
08.06.2017 09:38-1Кортекс, во первых, сильно избыточный для этой задачи, во вторых я его практически не знаю. Потому был выбран 1886ВЕ5У.
"Я выбрал не современный процессор, а тот, про который я что-то уже знаю, пусть и с устаревшей на десяток лет архитектурой. Так вот, чуваки, оказывается, он не современный, прикиньте?"
Psychosynthesis
08.06.2017 14:43Не, не так. Скорее:
«Чуваки, я тут погуглил, так вот у нас оказывается на сайте ни слова про наш МК нету, хотя вроде всем интересно, мне тут довелось с ним поработать чуток, об этом я и расскажу»
Улавливаете разницу?vvzvlad
08.06.2017 18:28Рассказали, молодец, кто же спорит. Я к тому, что вы сами выбрали его, потому что архитектура была вам знакома, а не взяли более современный. Ну упс, старая IDE и прочие приколы — в общем-то, ожидаемо.
Error1024
10.06.2017 04:38+1Демопример за деньги и компилятор родом из 80-90-х это конечно мощно :)
Но это логичный итог вливания/распила денег в «нанотехнологии», и игнорирование состояния электронной промышленности.
Это печально. Но это тот максимум, что выдает наша МП, пока выдает, щас у государства сново новые приоритеты, враги, распилы и т.д.
alex93vzlom
11.06.2017 23:59+2Да, документация у миландра специфичная. Недавно как раз пытался побороть 1986ве1т.
Вроде все изложено последовательно и одним файлом, но стиль изложения постоянно меняется. Либо часть документации просто скопированный перевод с доков стм-ок (что вероятнее всего, т.к. при гуглении некоторых моментов находятся абзацы слово в слово по стм32), либо пол пункта написано одним человеком, вторая половина другим — и они друг друга недолюбливают.
Ну и встречаются ошибки иногда: в начале написано, что регистр делает одно, в конце в таблице расписано что оказывается другое.
Немного специфично чтобы пытаться кодить под отечественный МК изучать для этого инструкции по зарубежным, когда до этого ничего сложнее ардуинки в руках не держал.
RomeoGolf
12.06.2017 10:58+1пол пункта написано одним человеком, вторая половина другим — и они друг друга недолюбливают.
Вот почти слово в слово мои слова! Недавно коллегам сказал, что люди, вдвоем писавшие этот пункт, друг с другом не здороваются.
vanxant
Ну положим с сохранением регистров при прерываниях всё как раз понятно. У прерывания есть нереентерабельная часть (обычно её стараются уместить между командами на запрет прерываний и на их разрешение) и реентерабельная, в которую один тип прерываний может войти одновременно дважды, трижды и т.д, Проблема с нереентерабельной частью в том, что потенциально это место потери сигналов прерываний, поэтому эту часть стараются делать как можно короче, буквально каждый такт считают. И вот тут сохранения ненужных регистров ну вот никому не нужны.
Psychosynthesis
Может можно их до входа в нереентерабельную часть сохранять?
Прикол ещё в том, что, как я понял, сохранить можно всего шесть регистров, что тоже не фонтан, как по мне.
vanxant
Я, конечно, не знаю как там в пиках устроено, но чаще всего вход в прерывание сразу включает запрет на обработку прерываний. А вот уже разрешать прерывания нужно ручками.
Тут смотрите какая вещь. У вас может быть довольное тупое устройство, подключенное к довольно тупому контроллеру шины. Контроллер шины по совместительству может работать «тупым» контроллером прерываний для этой шины, который реализует очередь прерываний ёмкостью аж 1 прерывание.
При входе в обработчик прерываний вам нужно а) как можно скорее сбросить прерывание на контроллере, чтобы он мог принимать следующие прерывания от других устройств; и б) возможно, прочитать данные из выходного буфера дёрнувшего прерывание устройства, если например длина этого выходного буфера составляет 1 слово (говорю же — ну, тупые устройства).
Это было описание нереентерабельной части, для её реализации достаточно 1-2, ну максимум 3 регистра. Зачем целых 6 регистров сохранять и потом восстанавливать назад?
Psychosynthesis
Ну… я не говорю что это принципиальный вопрос. Мне (как потребителю) это удобнее. Например в PIC18 я над таким даже не думаю, а весь процесс кодинга лишь немного отличается от программирования под «взрослые» компы — в ассемблер PIC я вообще никогда не заглядывал.
LeonidPr
Насколько я помню, у этого контроллера нет стека. Точнее он есть, аппаратный, недоступный программисту и там сохраняется адрес возврата при вызовах подпрограмм ну и прерываниях. Т.е. как я понимаю, регистры сохранять просто некуда. можно сделать свой стек, там есть регистры косвенной адресации. Вроде была у них возможность автоинкремента/автодекремента.
Psychosynthesis
Стек есть, в даташите даже есть пример на асме как сохранение регистров реализовать.
RomeoGolf
Тут такое дело… Если есть оперативка (а куда ж без нее), то сохранить регистры легко. И можно реализовать стек в оперативке программно. А бывает специальный стек под это дело. Так что, стек (как бы) есть везде, но «есть нюанс». Автосохранение регистров обычно работает как раз с аппаратным стеком, правда, я про такое только читал, а с чем вживую работал — не попадалось.
kdekaluga
С PIC'ом не знаком, пишу иногда программки под 8-бит AVR на ассемблере. Так там 32 регистра, PUSH или POP каждого занимает по 2 такта (вместе — 4). Иногда для экономия времени, зная, что прерывание нереентрабельно, а программа небольшая, использую сохранение не в стек, а в другие регистры (которые не используются в остальной программе), оно занимает 1 такт на 2 регистра (в 4 раза быстрее). В итоге, если бы AVR сохранял что-то сам, получилось бы медленнее.
Исключение, возможно — регистр флагов (SREG в AVR). Чтобы его сохранить, надо две команды, а сохранять его надо в 99.9% случаев. Но когда писал на старичке Z80, в нем тоже ничего не сохранялось само, я привык.