В статье речь пойдёт про отечественный МК фирмы Миландр 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 это компактность и возможность работать без установки, но не думаю, что это такие уж критичные моменты.
Очень надеюсь, что за ближайшие несколько лет разработчикам удастся подтянуть этот показатель к уровню ведущих брендов.
Автор: Psychosynthesis
