Все никак не решусь сделать первый шаг в переходе на ARM, и сдерживает меня в этом программатор-отладкичик. Сегодня погуглил, и насколько смог разобраться, у всех ARM-контроллеров единный интерфейс отладки и программирования, потому можно использовать один программатор для микроконтроллеров различных производителей. Начал искать конкретные программаторы. Нашел J-Link, оригинал SEGGER стоит от 300$, а его клон от 15$ за версию V8 и выше 30$ за V9 (последняя). Начитался и о проблеммах клонов, т.к. оригинальный софт может изх выявлять и стрирать внутри них прошивку (потом начинается "танец" с перемычками, разными версиями софта и т.д.). Пока сколняюсь к клону J-Link V8 за 15$, микроконтролеры Nuvoton с ядром Cortex-M0 и M4 (есть локальный дистрибютор). Честно говоря, жаба немного давить отдавать 15$ за отладчик, т.к. не уверен на 100% в правильнгсти выбора для домашнего саморазвития. Пока все мои нужны выполняют 8-ми бытные PICи, попробовал и 16-ти битный PIC24 (переназначение виыводов периферии - клас!).
Интересует ваше мнение по поводу программаторов, правильно ли я понял, что программатор универсальный (для различных производителей)? Чем пользуютесь? Функция отладчика интересует принципиально.
Я счас сюда только смотрю. http://tim4dev.com/2015/03/esp8266-wifi-direct-programming/ Пока для нас это направление новое неосвоенное и ...возможно перспективное. Ранее что то похожее на BT хотели получить года так хреназнаетскока назад, но счас уже не хочут. А преимущества есть. Проверьте их для себя что будете применять в изделиях на перспективу. Да и ещё они все идут платкой, как раз для радиолюбителя, кто столкнулся с 0.5мм ножками плохо досягаемыми в ЛУТе, тут сразу в разумных ценах основная деталь спокойно в ЛУТ вставляется. Гальванически развязанные CAN и другие промышленные и прочее просто делаются заменой всё wifi соединением и уходом с них. Ну это как бы начало, а что будет в конце никто не знает. http://homes-smart.ru/index.php/oborudovanie/bez-provodov-wi-fi/62-besprovodnoj-... А уж как делают такие вещи https://github.com/squix78/esp8266-oled-ssd1306 тут STM32 монстр и ... просто отдыхает. А это ведь всё делается втычной разводкой электроникой. Сам был в ахуе когда первый раз увидел.
Есть у меня такие. Игрался с ними, правда свою прогу не писал. Но смысл МК в том, что я могу, к примеру, запустить ШИМ с нужной частотой и скважнгостью, в каждый момент начала периода ШИМ запускать АЦП на преобразование и с помощью компаратора ограничивать скважность ШИМа. И это все работает само по себе, аппаратно. При наличии DMA МК может без участия ядра передавать данные, к примеру, на дисплей по SPI на МГц-ных частотах. Гальваническая развязка нужна только для линий, которые выходят за пределы платы, да и то не всегда.
viczai: А это ведь всё делается втычной разводкой электроникой
Разновидность "Ардуины". Когда на макетке собрать-попробовать, то удобно, но для законченного устройства очень громоздко и крайне энергоемко (если питание не сеть 220В).
Из последних новостей из семейства мк. http://app.contact.nxp.com/e/es.aspx?s=1764&e=184495&elqTrackId=0503bce319804656... Скрестили в NXP linux и мк. Что получится пока никто не знает. Т.е. мк 900 МГц и вся мк периферия полная, АЦП,SPI, I2C, NFC, а не как для андроидов усечённая типа АЦП 4 канала, а других просто нету. Одна графика и встроенные GSM BT WiFi.
То есть в него и виндос можно втолкать, Вы на это намекаете. Да всё хорошо и линуксом, а как хоть что то рабочее будет выглядеть, я даже не представляю. Опять винчестер=SD карта и понеслась работа программера на ос, а не на конкретно тех процесс, вот я про что, нет тут моего понимания. И там то же ничего не рассказано, хоть на какое применение это нацелено. Нее, от мощности никто не откажется. Но не представляю. Подскажите. Пофантазируйте. Теоретически как идея хорошая. Практика, вот в этом то и вопрос.
Мощность сейчас уходит не на ускорение решения задачи, а больше на удобство программиста. Придумали "виртуальные языки", которые крутится в интерпретаторе и на лету конвертируется в машинные коды под конкретное железо. Для программиста удобство в том, что на разном железе работает, но ценою есть увеличение требований к ОЗУ и железу, чтобы успевать еще и переводить "универсальные машинные коды" в "машинные коды конкретного железа". И получается, что та-же задача выполняется за то-же время, хотя железо намного мощнее стало. Это я образно.
Вспомните Volcov Commandor. Это была файловый менеджер весом менее 32 кбайт, при этом функционал был наравне с Norton Commander, который весил мегабайты и с дискеты 5.25" очень долго и нудно грузился
Честно говоря, с Линуксом дела не имел и не совсем представляю, как идет адаптирование ядра, и как потом с "высокого уровня" работать с периферией на "низком уровне", т.к. нередко библиотеки не оптимальны (в плане ресурсов) для выполнение конкретной задачи - плата за универсальность. Сейчас краем глаза поглядываю на RealTimeOS для микроконтроллеров, т.к. уже лень вручную изобретать многозадаточность (делить выполняемую программу на маленькие кусочки и по очереди выполнять разные задачи).
Летом таки купил отладочную плату на 32х АРМ Cortex-M0, помигал светодиодами, пообщался по I2C-шине и пока отложил, решаю текущие задачи на 8-ми битниках
Сергей К: И получается, что та-же задача выполняется за то-же время, хотя железо намного мощнее стало. Это я образно.
Образно, но на 100% верно.
Сергей К: Сейчас краем глаза поглядываю на RealTimeOS для микроконтроллеров, т.к. уже лень вручную изобретать многозадаточность
В большинстве случаев верный подход. Но если требуется на слабом железе выжать максимум, то RTOS начинает тормозить. И тут опять два выхода - умощнять железо, или программировать на более низком уровне (вплоть до ассемблера). Сознаюсь, искусство писать на ассемблере практически утратил, не скажу что совсем безнадёжно, но страшно лень Тем более, что компиляторы С достигли такого совершенства, что ассемблер выигрывает всего 1.5 ... 2.5 раза. А всякого рода интерпретаторы это просто пожиратели вычислительной мощности. Оправдывает их применение только кросс-платформенность.
P.S. а знаменитый Волков командер сделан именно на ассемблере.