- PVSM.RU - https://www.pvsm.ru -
В статье речь пойдёт про отечественный МК фирмы Миландр 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
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/programmirovanie/257284
Ссылки в тексте:
[1] Источник: https://habrahabr.ru/post/330384/
Нажмите здесь для печати.