Comments 259
Похожа на аналогичную, с дисплеем, но тут, я смотрю, вообще ничего кроме контроллера и питания.
Даже транзистор на подтяжку USB пожалели…
Цену не углядел сначала, 10 баксов?
Тогда норм)
Даже транзистор на подтяжку USB пожалели…
Цену не углядел сначала, 10 баксов?
Тогда норм)
Да, все просто и минималистично. Размер, комплектация, цена :)
Кстати, на плате с LCD какие-то проблемы с USB — не хочет инициализироваться, видимо подтяжка неправильно настроена.
Кстати, на плате с LCD какие-то проблемы с USB — не хочет инициализироваться, видимо подтяжка неправильно настроена.
У меня три платы на STM с LCD, нигде проблем не замечал.
Как отладочная, наверное, приятнее та, что с LCD, есть что пощупать, а избыточности и монструозности в ней не чувствуется. Правда стоит она подороже, 30 баксов почти.
Как отладочная, наверное, приятнее та, что с LCD, есть что пощупать, а избыточности и монструозности в ней не чувствуется. Правда стоит она подороже, 30 баксов почти.
Ну вот у меня почему-то не хочет подключаться, скорее всего дело в подтяжке. Не разбирался в деталях, пока оставил ее.
На том же STM32F103VE у меня есть другая плата, более удобная для отладки.
Кстати, моя с LCD стоила еще дороже — почти 50, правда брал давно.
Кстати, а пример кода под нее для тач. скрина есть?
На том же STM32F103VE у меня есть другая плата, более удобная для отладки.
Кстати, моя с LCD стоила еще дороже — почти 50, правда брал давно.
Кстати, а пример кода под нее для тач. скрина есть?
попытка продвинуть сайт?
Если девайс отключить, то программа не сможет корректно закрыть COM-порт.
Это почему?
Потому что дескриптор будет некорректным. Прога об этом не узнает — нет способа узнать о том, что девайс исчез, если мы работаем с COM портом. Потому что COM порт это — это по сути файл. Ситуация такая же как выдернуть флешку из компа, с открытым на ней файлом Word. Word очень обидится, что файл посреди работы отобрали.
вообще то есть — можно просто через определенные промежутки времени слать команду в комп, а он уже смотрит — если по таймауту не получили команду — либо ребутаем ком порт, либо закрываем. Но usb конечно для пользователя удобней и быстрее
Вы пробовали? А я пробовал — при попытке записать в отсутствующий девайс, который просто выдрали из компа, мы получим Exception. И все на этом. Порт ни закрыть ни снова открыть при подключении девайса, пока не перезапустим прогу. Разница капитальная. К тому же есть проблемы, когда девайс подключен постоянно к компу, а комп уходит в слип и возвращается. Там проблемы еще больше. Комп может запросто потерять несколько пакетов, пока просыпается, и пакеты битые могут быть.
С USB HID такого не бывает. И девайс может отслеживать спит комп или нет, и обмен гораздо правильнее, надежнее и удобнее организуется. Я с COM портами работал начиная с 2001 года. В разных девайсах. С обеих сторон — и с МК и с ПК. И могу сказать, их достоинство — распространенность и простота. На этом они заканчиваются, а недостатков море.
С USB HID такого не бывает. И девайс может отслеживать спит комп или нет, и обмен гораздо правильнее, надежнее и удобнее организуется. Я с COM портами работал начиная с 2001 года. В разных девайсах. С обеих сторон — и с МК и с ПК. И могу сказать, их достоинство — распространенность и простота. На этом они заканчиваются, а недостатков море.
да ладно вам страху нагонять — все нормально программируется — USB удобен для пользователя и совершенно не удобен для программиста, com порт в этом плане гораздо удобнее, а поскольку вы можете как писать программу на стороне ПК, так и программу на стороне устройства — наладить коммуникацию с учетом всех исключений — не составляет проблем
Лично мне, как программисту, USB гораздо удобнее. Не проще, нет, но удобнее. Это да. удобство — это не тупой код, который глючит при работе девайса из-за его принципиальной ущербности, а тот, который работает надежно.
Для меня работа с девайсом, когда его не надо опрашивать, а он сам шлет данные по готовности и в пакетом режиме очень удобна.
Я написал свою реализацию пакетного обмена по USART, но USB все равно удобнее и функциональнее. Я могу в одном девайсе сделать и управление компом и кучу событий и обмен данными и вообще всего дофига, чего на UART не сделать никак. Это я и ценю в USB. А еще то, что не нужно искать какой же из десятков COM портов приинадлежит моему девайсу, не нужно ставить драйверов FTDI, CP2102 и тому подобных конвертеров. Не нужно самих конвертеров в конце концов. Пара резюков и все — девайс напрямую подключается к компу. Это удобно.
Для меня работа с девайсом, когда его не надо опрашивать, а он сам шлет данные по готовности и в пакетом режиме очень удобна.
Я написал свою реализацию пакетного обмена по USART, но USB все равно удобнее и функциональнее. Я могу в одном девайсе сделать и управление компом и кучу событий и обмен данными и вообще всего дофига, чего на UART не сделать никак. Это я и ценю в USB. А еще то, что не нужно искать какой же из десятков COM портов приинадлежит моему девайсу, не нужно ставить драйверов FTDI, CP2102 и тому подобных конвертеров. Не нужно самих конвертеров в конце концов. Пара резюков и все — девайс напрямую подключается к компу. Это удобно.
А уж HID и вовсе приятен, дров на хосте не нужно, программировать удобно.
А то! и функционал офигенный. не понимаю тех, кто делает CDC, когда есть HID. И потом ищет дрова под это убожество. А все потому, что кроме как UART они ничего не знают для коммуникаций.
CDC тоже не требует драйверов в общем случае.
В каком общем? Не только драйвер потребует но и либу скорее всего. Большинство девайсов делается как libusb. А я терпеть не могу таскать за приложением еще и dll лишние. особенно когда без них можно обойтись. Не надо плодить лишних сущностей. UART для взаимодействия с компом на постоянной основе подходит плохо.
я согласен, все зависит от задачи, на usb конечно это все лучше делается, но вы написали, что на COM порте этого сделать невозможно — возможно, была бы смекалка и желание)
Невозможно. То, что хочу я невозможно. даже приближенно реализовать — нужны усилия лишние. Вопрос — зачем? Зачем заниматься извратом, когда есть в девайсе встроенный функционал правильный, быстрый, надежный, удобный.
Я знаю, что есть любители оправдывать занятия ерундой и кривые реализации, но я их не поддерживаю и оправданий им нет.
Я знаю, что есть любители оправдывать занятия ерундой и кривые реализации, но я их не поддерживаю и оправданий им нет.
А какие там максимальные скорости в случае с HID а то нам из контроллера надо максимум возможностей выжать. Как минимум мегабит а лучше два или десять даже.
Не тестировал, но HID вообще говоря не особо предназначен для суперскоростей с большими объемами. Когда нужно максимум выжать, тут и работать надо как следует — например сделать Mass Storage класс. Драйверов тоже не требует, передача Bulk, скорости — сколько может USB. Можно просто рассматривать как флешку и писать/читать файлы. Если не хватает — ставьте старший МК — там есть USB HS поддержка.
Сейчас мы вообще на ethernet'е и tcp/ip сидим банально, но с его настройкой пришлось конкретно так повозиться.
Ну Ethernet только на coonectivity line или F4, а там совсем другие цены, да и камушки покрупнее будут :)
Кстати, а разработка секретна или поделитесь?
Кстати, а разработка секретна или поделитесь?
Да нет, ПО для фрезерных станков, способное работать в микрошаговом режиме, в отличии от популярных ширпотребных решений. Вот для того, чтобы успевать ездить в микрошаге и нужен интенсивный обмен с контроллером.
Я вам расскажу одну байку, основанную на реальных событиях. Делали мы один девайс как раз на вышеописанном процессоре. Одна индустриальная машинка, управляемая с компа. Модулей несколько, от трёх до много, все подключены к компу и им дирижируются. Увы, изначальный дизайн платы был не наш, потому на некоторые решения повлиять было сложно в процессе работы — у нас были примерно 10 готовых плат, в которые мы могли вносить минимальные изменения, на них нужно было отладить работу, чтобы потом заказать редизайн и новые платы.
Так вот, изначально когда-то было принято решения, что устройства управляются через RS-232. Потом наши предшественники решили, что это не очень OK, потому как в компах количество компортов со временем стремится к нулю, и заменили их на USB CDC. На платах были разведены USB-хабы, девайсы были подключены друг к другу по цепочке, а хвост втыкался в USB-порт управляющего PC. В итоге софт переделывать практически не пришлось. И вот в таком виде девайс попал к нам.
Вроде как всё работало замечательно. До поры до времени. А именно, в нашем устройстве было много сервомоторов, шаговых двигателей, соленоидов и прочей трасцы, которая давала нехилые помехи в сеть и грозила отсечь пальцы и прочие неаккуратно оставленные на рабочих поверхностях части тела, а потому в составе девайса предусматривались средства безопасности. Предполагалось, что специальный ключ размыкает цепь, которая обесточивает некоторый контур, а специальный модуль с релюхами обесточивает всё остальное, когда это заметит. Интерлок такой, в общем. Ну а потом, соответственно, при устранении опасной ситуации все эти моторы и прочая все вместе включались, пусть и с небольшими задержками.
Вот когда мы начали этим интерлоком часто пользоваться, выяснилось, что одновременное выключение нескольких десятков работающих моторов и прочего просто начисто убивает USB. Т.е. сбрасываются все хабы и вообще всё, что есть на шине. Более того, ну ладно, сбрасываются они — и пусть, ведь подключаются сразу же назад. Оказалось, что не каждая операционная система с этим умеет бороться. К нашему сожалению, наши предшественники решили писать софт на C# и крутить его на Windows XP Embedded. Так вот, при каждом срабатывании интерлока ОС выпадала в «синий экран» в драйвере USB CDC. В качестве пробы я подключал свой лаптоп с Linux — устройства пропадали и возвращались, система никак не страдала. Мы перепробовали всё. Пробовали определять пропадание устройств, чтобы сразу же закрывать порт, думали о том, чтобы переписать нафиг драйвер (в каком-то SDK от MS есть исходники простого CDC-драйвера), была мысль даже написать userspace-драйвер на libusb (почти получилось, надо сказать). В конце концов избавились вообще от USB в пользу мультипортовой PCI-платы расширителя RS-232 и десятка экранированных кабелей. При всех теоретических недостатках RS-232 работало намного стабильнее.
Ну а следующая редакция платы просто использовала CAN (как и стоило бы делать с самого начала).
Так вот, изначально когда-то было принято решения, что устройства управляются через RS-232. Потом наши предшественники решили, что это не очень OK, потому как в компах количество компортов со временем стремится к нулю, и заменили их на USB CDC. На платах были разведены USB-хабы, девайсы были подключены друг к другу по цепочке, а хвост втыкался в USB-порт управляющего PC. В итоге софт переделывать практически не пришлось. И вот в таком виде девайс попал к нам.
Вроде как всё работало замечательно. До поры до времени. А именно, в нашем устройстве было много сервомоторов, шаговых двигателей, соленоидов и прочей трасцы, которая давала нехилые помехи в сеть и грозила отсечь пальцы и прочие неаккуратно оставленные на рабочих поверхностях части тела, а потому в составе девайса предусматривались средства безопасности. Предполагалось, что специальный ключ размыкает цепь, которая обесточивает некоторый контур, а специальный модуль с релюхами обесточивает всё остальное, когда это заметит. Интерлок такой, в общем. Ну а потом, соответственно, при устранении опасной ситуации все эти моторы и прочая все вместе включались, пусть и с небольшими задержками.
Вот когда мы начали этим интерлоком часто пользоваться, выяснилось, что одновременное выключение нескольких десятков работающих моторов и прочего просто начисто убивает USB. Т.е. сбрасываются все хабы и вообще всё, что есть на шине. Более того, ну ладно, сбрасываются они — и пусть, ведь подключаются сразу же назад. Оказалось, что не каждая операционная система с этим умеет бороться. К нашему сожалению, наши предшественники решили писать софт на C# и крутить его на Windows XP Embedded. Так вот, при каждом срабатывании интерлока ОС выпадала в «синий экран» в драйвере USB CDC. В качестве пробы я подключал свой лаптоп с Linux — устройства пропадали и возвращались, система никак не страдала. Мы перепробовали всё. Пробовали определять пропадание устройств, чтобы сразу же закрывать порт, думали о том, чтобы переписать нафиг драйвер (в каком-то SDK от MS есть исходники простого CDC-драйвера), была мысль даже написать userspace-драйвер на libusb (почти получилось, надо сказать). В конце концов избавились вообще от USB в пользу мультипортовой PCI-платы расширителя RS-232 и десятка экранированных кабелей. При всех теоретических недостатках RS-232 работало намного стабильнее.
Ну а следующая редакция платы просто использовала CAN (как и стоило бы делать с самого начала).
Вы зафейлили топологию платы, разведя без учета защиты от движков и мусора, что он активно поставляет в схему. Либо использовали сторонние девайсы не приспособленные для того. USB тут совсем не при делах. CAN конечно лучше будет, но и с ним могут быть фейлы если плата кривая.
Ну USB сам по себе не пром. стандарт, там длина кабеля, если я правильно помню, по стандарту около метра. В таких условиях как у вас из простых шин часто 485 юзают, ибо дифференциальная (в отличие от 232).
Почему дескриптор будет некорректным? Можно ничего не подключать к порту и писать туда сколько угодно. Все будет корректно, только ответа не будет. Проблема у вас не в порте и не в девайсе, а в программе, которая с портом работает.
вообще есть, и работает. реинициализация вполне прекрасно ловится.
есть проблема с FTDI чипом, который может от ЭМ помехи зависнуть так, что только перезапуск USB порта по питанию работает, но на вин8 это починили.
на линухе нет проблем и так с ними
есть проблема с FTDI чипом, который может от ЭМ помехи зависнуть так, что только перезапуск USB порта по питанию работает, но на вин8 это починили.
на линухе нет проблем и так с ними
Ок, как? пример под Win7 или 8
на питоне pyserial обычный.
обормачиваем в try: except: — и работает даже когда отваливается как ридер, так и врайтер.
после этого надо просто открыть порт еще раз с небольшим таймаутом
обормачиваем в try: except: — и работает даже когда отваливается как ридер, так и врайтер.
после этого надо просто открыть порт еще раз с небольшим таймаутом
А теперь давайте попробуйте это в реальной жизни. USB CDC на Windows — да больше никогда в жизни.
Я в реальной жизни это и использую. FTDI, в форме VCP — работает без проблем.
Единственная проблема, которая есть — это WinXP/Win7 при высоком уровне ЭМ помех.
Но даже там нашел способ — выключается-включается корневой USB хаб, и это обесточивает нижестоящий, и требуемый порт — всё отвисает и начинает работать.
Единственная проблема, которая есть — это WinXP/Win7 при высоком уровне ЭМ помех.
Но даже там нашел способ — выключается-включается корневой USB хаб, и это обесточивает нижестоящий, и требуемый порт — всё отвисает и начинает работать.
Тоже присмотрел такую плату, только потестировать никак не доберусь… А не встречали что-то подобное но с ZigBEE на борту? Желательно чтобы цена была минимальной.
С ZigBee не может быть минимальной по определению — стандарт закрытый. Xbee еще куда ни шло. А зачем? любые беспроводные интерфейсы правильнее располагать отдельно, чтобы не мешать антенне.
Xbee и ZigBee кажется согласуются, так что можно и его. Для меня в данном случае критичны размеры (максимум 60*60 мм), цена (не более 25-30 у.е.) и хотя бы 20 пинов I/O. Готовлю один проект где потребуется много таких модулей, потому параметры и критичны. Правильней оно конечно да, но вот тут например ничто никому не мешает, только к сожалению радиоканал не тот? который мне нужен.
Ну когда нужно много, то Ariman прав — можно и самому развести. Тем более, что это не ПЛИС разводить. 48 ножек вполне можно и в 1-2 слоя уложить.
Можно то можно, но как показывает практика нервов, времени и денег иногда на самостоятельное изготовление уходит больше, чем если покупать модули и из них что-то делать. Я сейчас уже стараюсь делать платы только если они совсем не типовые, нужно сделать быстро или покупные модели стоят неправомерно дорого.
А плану нашел вот такую SPZB32W1A2.1 и стоит не очень дорого — меньше 600р. Надо посмотреть что она из себя представляет.
А плану нашел вот такую SPZB32W1A2.1 и стоит не очень дорого — меньше 600р. Надо посмотреть что она из себя представляет.
Времени и нервов уж точно. Я несколько устройств сделал, могу сказать, что это самая трудная часть — разработка и изготовление железки правильно, так. чтобы она работала.
За 1 модуль это многовато. Учитывая что ни антенны ничего подобного нет.
Модуль на 100мВт на 433 или 915 МГц с антенной, готовый к использованию столько стоит (3DR Radio).
За 1 модуль это многовато. Учитывая что ни антенны ничего подобного нет.
Модуль на 100мВт на 433 или 915 МГц с антенной, готовый к использованию столько стоит (3DR Radio).
Да, модель очень интересная, наверняка для каких-то задач этот модуль подходит, но MASH-сеть на нем не построить, по крайней мере без дополнительного геморроя и хитрого программирования (а может быть и вообще это окажется невозможным).
Судя по документации A — означает встроенную антенну, а на картинке в документации изображен модуль с внешней антенной.
Судя по документации A — означает встроенную антенну, а на картинке в документации изображен модуль с внешней антенной.
Xbee — это одна из железок, которая говорит по ZigBee, а вам нужен 802.15.4, скорее всего :-)
Перечесал кучу IDE для работы с STM32, остановился на CooCox IDE (http://coocox.org/index.html).
Там уже есть все что нужно, включая поддержку STLink, J-Link и т.д.
Там уже есть все что нужно, включая поддержку STLink, J-Link и т.д.
CooCox есть, но у него проблема с тем, что нет поддержки С++ и не будет никогда. А есть проекты, в которых код написан на С++ и переписывать его долго и муторно.
К тому же мне не нравится то, что он — обрезанный Eclipse. Настроить в нем что-то под себя почти нереально. Надо либо рыться в конфигах либо вообще никак. В частности никак не добавить недостающие горячие клавиши. Ну и eclipse не самое быстрое, что есть.
EmBlocks в native коде написан, хорошо расширяется (в основе его CodeBlocks, который я тоже юзаю), он не требует установки, можно носить на флешке. Проекты из CooCox легко в него переносятся, я перенес пару своих проектов. Редактор в EmBlocks настраивается очень неплохо. В общем, с кастомизацией у него лучше. Но CooCox тоже использую, просто он тяжеловесный и медлительный, но проверить идею по-быстрому в нем не проблема.
К тому же мне не нравится то, что он — обрезанный Eclipse. Настроить в нем что-то под себя почти нереально. Надо либо рыться в конфигах либо вообще никак. В частности никак не добавить недостающие горячие клавиши. Ну и eclipse не самое быстрое, что есть.
EmBlocks в native коде написан, хорошо расширяется (в основе его CodeBlocks, который я тоже юзаю), он не требует установки, можно носить на флешке. Проекты из CooCox легко в него переносятся, я перенес пару своих проектов. Редактор в EmBlocks настраивается очень неплохо. В общем, с кастомизацией у него лучше. Но CooCox тоже использую, просто он тяжеловесный и медлительный, но проверить идею по-быстрому в нем не проблема.
народные умельцы прикрутили к нему поддержку C++, но на самом деле чаще всего в проектах под МК с низкоуровневым программированием в C++ нет нужды просто
А вы видели сколько манипуляций для этого нужно и как криво это реализовано? Вот пусть умельцы этим и пользуются.
С++ мне лично нужен. По эффективности кода он бывает даже лучше С, это уже тоже проверено, в том числе и для МК. А писать удобнее.
У вас нет нужды? я рад за вас. Многим разработчикам хватает блокнота и они готовы каждый раз писать make руками или переделывать выдранный из другого проекта. Я нет.
Я люблю проверять идеи быстро — нажал кнопочку создать проект, получил заготовку, в которую пишу только нужный мне код и нажав две кнопки получаю прошитый девайс. Вот это удобство. Если мне нужно для проверки идеи создавать и настраивать новый проект более 1 минуты, то я этого делать не буду.
С++ мне лично нужен. По эффективности кода он бывает даже лучше С, это уже тоже проверено, в том числе и для МК. А писать удобнее.
У вас нет нужды? я рад за вас. Многим разработчикам хватает блокнота и они готовы каждый раз писать make руками или переделывать выдранный из другого проекта. Я нет.
Я люблю проверять идеи быстро — нажал кнопочку создать проект, получил заготовку, в которую пишу только нужный мне код и нажав две кнопки получаю прошитый девайс. Вот это удобство. Если мне нужно для проверки идеи создавать и настраивать новый проект более 1 минуты, то я этого делать не буду.
тем самым вы сами себе роете яму — программирование МК это в первую очередь знание устройства на низком уровне, потом уже удобство программирования, преимущество C++ для ПК — возможность использования фреймворков и т.д. и т.п., программы для мк(если не ставить ОС) обычно довольно просты и не требуют возможностей C++ — без классов спокойно можно обойтись, используя структуры и указатели на функции — про создание проекта — никак не относится к C/C++ — зависит от среды разработки
Ничего подобного :)
Вы давно распиливали девайс и изучали его на уровне транзисторов? Я нет. и не буду. Мне достаточно логики работы девайса и схемы из даташита. а в идеале и еще проще — только логики. Обойтись можно без чего угодно, но я люблю удобство, особенно когда оно бесплатное. можно и на одной руке ходить научитсья, а зачем?
У меня, например, программы не всегда просты, к тому же я часто использую код в последующих проектах и код на С переносить неудобно, а на С++ классы переносятся бесшовно. Я пишу и под МК и под ПК сам, один. Поэтому проект в целом может быть очень большим. Лишние телодвижения мне ни к чему.
Еще раз — если можно получить простоту и удобство бесплатно с точки зрения производительности и инструментария, то почему не получить?
Вы давно распиливали девайс и изучали его на уровне транзисторов? Я нет. и не буду. Мне достаточно логики работы девайса и схемы из даташита. а в идеале и еще проще — только логики. Обойтись можно без чего угодно, но я люблю удобство, особенно когда оно бесплатное. можно и на одной руке ходить научитсья, а зачем?
У меня, например, программы не всегда просты, к тому же я часто использую код в последующих проектах и код на С переносить неудобно, а на С++ классы переносятся бесшовно. Я пишу и под МК и под ПК сам, один. Поэтому проект в целом может быть очень большим. Лишние телодвижения мне ни к чему.
Еще раз — если можно получить простоту и удобство бесплатно с точки зрения производительности и инструментария, то почему не получить?
потому что в программировании МК — СИ это стандарт, а СИ++ — экзотика — вам просто проще будет договориться или адаптировать код с другими разработчиками
Ерунда, в том же STM32 STDPeriphLib есть заготовка под С++, чтобы корретно компилировалось. Так что проблем не будет.
А больше разработчиков потому, что вендоры ленятся сделать поддержку, опрадывая этосвоей ленью такими вот странными способами. С++ уже много лет как не то, что не экзотика, а мэйнстрим.
А больше разработчиков потому, что вендоры ленятся сделать поддержку, опрадывая это
Вы так наивно полагаетесь на STPL. А в ее код пробовали заглядывать? Там адский трешак, такое ощущение, что многое оттуда было написано индийскими студентами на зачет по лабе.
Кто сказал, что я на него полагаюсь? :) Просто с ним быстрее делать пробы, примерно как с Arduino — попробовал идею на платке — сделал свой девайс. Что там трешак, я видел. Но для большинства случаев работает. Когда не работает или нужен надежный чистый код, садимся и пишем сами. Чисто и аккуратно. Для экспериментов этого не требуется. Для несложных устройств — тоже.
Пример из мира ПК — есть VCL, есть MFC и куча других библиотек, они довольно увесистые, но добавляют удобства. Я могу написать программу на чистом WinAPI, но это как пилить ручным лобзиком морскую яхту.
Кстати, за статьи спасибо :)
Пример из мира ПК — есть VCL, есть MFC и куча других библиотек, они довольно увесистые, но добавляют удобства. Я могу написать программу на чистом WinAPI, но это как пилить ручным лобзиком морскую яхту.
Кстати, за статьи спасибо :)
Встречный вопрос на засыпку: Для чего в современных МК по 128кБ флеша?
в смысле? — есть меньше, есть больше
во первых программы даже на Си могут быть достаточно большими, во вторых — этот флеш можно использовать для своих нужд как энергонезависимую память
Это очень редко. Когда прикладная программа для МК весит СТОЛЬКО.
Как раз для бесконтрольного использования тяжелых языков это все и сделано.
Как раз для бесконтрольного использования тяжелых языков это все и сделано.
Прикладная программа может содержать большие таблицы констант, шрифты, изображения.
Да на C++, мне кажется, тоже не сделаешь настолько громоздкий код.
Можно данными забить, можно виртуальную машину какую, специфичную для области, вот этим самое оно.
Вон даже в АВР явамашину упихивали, в 8 кб…
Можно данными забить, можно виртуальную машину какую, специфичную для области, вот этим самое оно.
Вон даже в АВР явамашину упихивали, в 8 кб…
Когда девайс только и делает что дергает парой ног, я вообще не вижу смысла делать девайс. МК для меня — это в первую очередь обработка информации из реальногом мира. То есть интерфейс и интеллектуальная обработка сенсоров и управление исполнительными девайсами. Маленький такой компьютер. Давняя мечта. которая теперь — реальность. А не просто набор резисторов и транзисторов в одном корпусе, тупой как и раньше.
Самое ценное в МК — возможность писать программу любой сложности и связываться с ней извне.
Самое ценное в МК — возможность писать программу любой сложности и связываться с ней извне.
Это субъективщина.
Когда от девайса нужно только дергать ногами — это тоже девайс. И делать его в ряде случаев проще именно на МК.
Как пример могу привести устройство, которое переключает питание между насосами(неграмотная разводка отопления в цеху заставила переключать насосы, иначе один остается холодный почему-то).
Так вот… штука только и умеет, что раз в минуту переключать состояние реле. Можно было бы рассчитать мультивибратор… но зачем, если у меня вагон PIC12F629 и программатор и рыба под прогу под рукой.
Выставил таймер, прошил — свободен. Дело реально заняло минут 20 от начала до конца.
Без рассчетов и настройки. Тайминг — естественно отличный.
Когда от девайса нужно только дергать ногами — это тоже девайс. И делать его в ряде случаев проще именно на МК.
Как пример могу привести устройство, которое переключает питание между насосами(неграмотная разводка отопления в цеху заставила переключать насосы, иначе один остается холодный почему-то).
Так вот… штука только и умеет, что раз в минуту переключать состояние реле. Можно было бы рассчитать мультивибратор… но зачем, если у меня вагон PIC12F629 и программатор и рыба под прогу под рукой.
Выставил таймер, прошил — свободен. Дело реально заняло минут 20 от начала до конца.
Без рассчетов и настройки. Тайминг — естественно отличный.
Вот, чтобы не было «почему-то» МК должен не просто тупо переключать ножки, а должна быть обратная связь, которую он обязан учитывать прежде чем выключить или включить исполнительный девайс. На то он и МК, а не схема переключения реле с термостатом по принципу автомобильного радиатора.
Я считаю, что там где устройство может решить проблему, что им нужно управлять и следить за ним, оно должно ее решать. В этом ценность МК — возможность к исполнительным устройствам и сенсорам прикрутить логику.
Я считаю, что там где устройство может решить проблему, что им нужно управлять и следить за ним, оно должно ее решать. В этом ценность МК — возможность к исполнительным устройствам и сенсорам прикрутить логику.
Java это уже извращение на МК. Squawk для cortex M3. Хм даже на роутерах с 128Мб RAM и 500MHz MIPS процом Java SE крайне неотзывчива.
Это написано на С с использованием STM32StdPeriphLib. + Debug информация.
И это еще очень простой функционал. Я люблю функциональные девайсы.
А верх тупизны — это Hydra с встроенным интерпретатором .Net и то, что RPi предлагают программить на питоне! Вот это изврат. Там и так кот наплакал производительности и памяти.
И это еще очень простой функционал. Я люблю функциональные девайсы.
А верх тупизны — это Hydra с встроенным интерпретатором .Net и то, что RPi предлагают программить на питоне! Вот это изврат. Там и так кот наплакал производительности и памяти.
UFO just landed and posted this here
Мой текущий проект в DEBUG target имеет размер 40 кБ. Там только примерно 2/3 функционала реализовано. Будет еще. Да, release будет гораздо компактнее, но пока так. И мучаться с тем, что не влезает не хочется.
Есть и мегабайтные. А в современных телефонах под baseband прошивку уходит порядка 20мбайт кода. Еще столько же на кастомизацию.
Но для не совсем простых задач — 128 кб это очень и очень нужно. И этого реально мало. Поддержка нормальной ОС — килобайта 32 минимум. Математика — сразу килобайт 20 прийдет из stdlib/newlib. Нужен защищенный загрузчик? отведите еще килобайт 10 на реализацию какого-нибудь нормального шифрования. Шрифты, тексты, протоколы. Что остается под логику? Да почти ничего.
Остальное — просто уходит под эмуляцию EEPROM. У EEPROM было гарантированное количество циклов перезаписи 1 млн. У флеша — 10 тысяч. Вот и посчитайте, во сколько раз нужно дублировать область перезаписи, чтобы добиться схожих характеристик.
Но для не совсем простых задач — 128 кб это очень и очень нужно. И этого реально мало. Поддержка нормальной ОС — килобайта 32 минимум. Математика — сразу килобайт 20 прийдет из stdlib/newlib. Нужен защищенный загрузчик? отведите еще килобайт 10 на реализацию какого-нибудь нормального шифрования. Шрифты, тексты, протоколы. Что остается под логику? Да почти ничего.
Остальное — просто уходит под эмуляцию EEPROM. У EEPROM было гарантированное количество циклов перезаписи 1 млн. У флеша — 10 тысяч. Вот и посчитайте, во сколько раз нужно дублировать область перезаписи, чтобы добиться схожих характеристик.
Не поверите, но нам на C не хватало.
А я разобрался с настройкой Eclipse + GNU ARM plugin + Sourcery CodeBench Lite + OpenOCD, и теперь у меня есть полноценная IDE с поддержкой C++ в том числе. Пишу для STM32, шью и отлаживаю через OOCDLink-s (на FT2232D) и через ST-Link 1 и 2.
А если не только похвастаться, а и поделиться со всеми статьей и сборкой?
Я про свой вариант на Emblocks вскоре напишу.
OpenOCD кстати довольно медленная, я пробовал этот вариант. Самый быстрый получается на ST-Link + его GDB сервер.
Неплохо черех ColinkEx с его GDB сервером.
Я про свой вариант на Emblocks вскоре напишу.
OpenOCD кстати довольно медленная, я пробовал этот вариант. Самый быстрый получается на ST-Link + его GDB сервер.
Неплохо черех ColinkEx с его GDB сервером.
Вылетело из головы. Вот моя статья. Правда, писал я её давно, и тогда я использовал проект stlink с GitHub. Сейчас в этом уже смысла нет, т.к. прекрасно работает OpenOCD. Есть ещё чья-то статья на we.easyelectronics.ru, где настраивают с OpenOCD.
А, видел :) Мне не понравилось, что нужно испортить STLink в Discovery чтобы заработало. Плюнул и вернул на место родной вариант, так его видят CooCox и другие. И OpenOCD очень медленно работал.
«Портить» нужно только под виндой. Может, вы какой-то старый OpenOCD использовали? Я начал им пользоваться с версии 0.6.0 — там всё, как надо: скорость прошивки 10-17 кбайт/c в зависимости от конкретного камня. Опять же, я всё делал в Ubuntu.
Ну так я под виндой и работаю. Linux у меня только на ноуте второй системой стоит для экспериментов. Хотя бы потому, что EmBlocks под линух нет. И я говорю не о скорости прошивки, а о скорости запуска дебаггера, подключения к плате и скорости отладки. Вот отладка идет очень медленно. Не знаю почему. STLinkGDB и тот, что идет с колин кексом существенно быстрее.
Ubuntu у меня стоит, но не радует удобством разработки под ней.
Ubuntu у меня стоит, но не радует удобством разработки под ней.
я достаточно долго разбирался, как работать с STM32F4 под ubuntu, и, на мой взгляд, самый адекватный howto embeddedprogrammer.blogspot.ru/2012/09/stm32f4discovery-development-with-gcc.html
С ним завелось все достаточно быстро, только единственное НО. Работает только с версиями, которые указал автор, с более свежими версиями почему-то у меня не завелось.
И вообще: порог вхождения программиста STM32F4 мне показался гораздо выше, чем FPGA Altera и Xilinx(с ними тоже есть заморочки). Про Wing вообще молчу.
Еще не по теме, но у меня есть FRDM-KL25Z c M0+, так под него запилили mbed.org/, она пока очень-очень далека от нормальной среды, но кроссплатфомренность создает магию.
С ним завелось все достаточно быстро, только единственное НО. Работает только с версиями, которые указал автор, с более свежими версиями почему-то у меня не завелось.
И вообще: порог вхождения программиста STM32F4 мне показался гораздо выше, чем FPGA Altera и Xilinx(с ними тоже есть заморочки). Про Wing вообще молчу.
Еще не по теме, но у меня есть FRDM-KL25Z c M0+, так под него запилили mbed.org/, она пока очень-очень далека от нормальной среды, но кроссплатфомренность создает магию.
Странная плата. Ее по идее сделать можно было еще меньше и получить более конкурентное преимущество.
Вот кому, скажите, нужен JTAG?
Пол человека на сотню его используют.
Вот кому, скажите, нужен JTAG?
Пол человека на сотню его используют.
согласен с тем, что можно было обойтись 4 проводами SWD. Но принято ставить этот громоздкий интерфейс 2х10. он и на программаторе ST-Link V2 и на CoLinkEx и вообще везде. С чистым SWD не видел. Я тоже ругаюсь периодически по поводу дуракцих плат. Уже писал на эту тему.
Таких плат можно вагон наделать, кстати — цены на производство очень сильно упали.
Только стоит ли? ИМХО делать плату с одной STMкой смысла нет, это же не процессорный модуль с DRAMами.
Только стоит ли? ИМХО делать плату с одной STMкой смысла нет, это же не процессорный модуль с DRAMами.
Можно, вот только сидеть и самому паять вагон плат смысла не вижу, а для экспериментов — самое то. Ну и девайс штучный собирать можно надевая вторым этажом исполнительную часть. Суть та же, что у Arduino. Это так называемая CoreBoard. Я себе заказал 5 штук STM32F103CB. Но нужно развести и изготовить плату, а в один слой я пока не смог сделать что-то приличное, а двухслойных сразу десяток заказывать пока нет нужды.
Почему не процессорный модуль? Это он самый и есть. Поэтому меня возмущают эти габариты в угоду устаревшему оборудованию.
SWD есть? Есть. Зачем тут 20пиновая пластмасска, которая занимает 20%(!) полезной площади.
SWD есть? Есть. Зачем тут 20пиновая пластмасска, которая занимает 20%(!) полезной площади.
Потому что он нафиг не нужен. Процессорный модуль с DRAM разработать на порядок сложнее, двусторонней платой не обойтись, разводить надо вдумчиво и правильно, иначе не заведется память. Поэтому использование таких вот модулей оправдано и снижает время и стоимость разработки.
А «модуль» на СТМке бессмысленный, чем клепать под него хостовую плату, можно его сразу на нее и поставить, техпроцесс тот же.
А «модуль» на СТМке бессмысленный, чем клепать под него хостовую плату, можно его сразу на нее и поставить, техпроцесс тот же.
Модуль никогда не бессмысленный. Всегда найдется тот, кто не захочет паять TQFP. Вот вообще никак не захочет.
Купит отладочную тогда.
Если он не захочет паять TQFP, то в его поделке уже пофиг на JTAG.
Если он не захочет паять TQFP, то в его поделке уже пофиг на JTAG.
Отладочная не стоит 10$ и несет на себе массу бесполезного мусора, в виде кнопочек, светодиодиков, разъемчиков и прочего-прочего.
Моя концепция: чем меньше — тем лучше, но не в угоду отсутствию юзабилити.
Вот яркий пример моей концепции habrahabr.ru/post/177803/
Хоть и не АРМ.
Моя концепция: чем меньше — тем лучше, но не в угоду отсутствию юзабилити.
Вот яркий пример моей концепции habrahabr.ru/post/177803/
Хоть и не АРМ.
См. пост. Эта отладочная стоит 10$. Это же не пинбоард, тут мало всего натыкано.
А вообще, проверить проект хватит любой отладочной, в том числе и с «мусором». А после проверки надо бы уже проектировать нормальную плату, а не пихать этих монстров в итоговый девайс.
А вообще, проверить проект хватит любой отладочной, в том числе и с «мусором». А после проверки надо бы уже проектировать нормальную плату, а не пихать этих монстров в итоговый девайс.
Правильно, монстров пихать в девайс не нужно. А что монстров делает монстрами — обилие ненужной периферии.
От того, что кто-то поленится развести место под контроллер на плате и сделает «нашлепку» в виде такого модуля, этот модуль монстром быть не перестанет, даже если там только контроллер.
Зато сделает быстро, и может даже денег заработает?
Совершенно точно. Я так вообще купил плату под штучный заказ, но оказалось, что она вообще полезна и удобна :)
Это верно в случае с многослойными платами и тяжелыми процессорами. Если речь идет об TQFP — STMке, то никакого «зато» не будет.
.
Это очень расплывчато. Ваяющие сайтики на PHP тоже могут заработать 200$ в день ничего не паяя.
Хостовая плата из воздуха появится? И модуль к ней сам прилипнет? Или как вы собрались без пайки и изготовления платы этот модуль использовать?
Если речь о макетке, тогда, опять же, это значит, что требования к габаритам у вас более чем мягкие.
Поэтому случай, когда «я могу себе позволить делать нашлепки и использовать макетку без пайки, но не могу позволить наличия там одного 20-контактного разъема» очень и очень редок, вырожден почти.
Хостовая плата из воздуха появится? И модуль к ней сам прилипнет? Или как вы собрались без пайки и изготовления платы этот модуль использовать?
Если речь о макетке, тогда, опять же, это значит, что требования к габаритам у вас более чем мягкие.
Поэтому случай, когда «я могу себе позволить делать нашлепки и использовать макетку без пайки, но не могу позволить наличия там одного 20-контактного разъема» очень и очень редок, вырожден почти.
удалил
Очень даже будет. Я недавно 200$ за день заработал, и при этом ничего не паял.
Хотя мог бы… Но не захотел, потому что было бы не 200$ за день, было бы 200$ за два дня.
Хотя мог бы… Но не захотел, потому что было бы не 200$ за день, было бы 200$ за два дня.
Вот лично я не хочу ни травить ни паять ни тем более тратить время и разводить эту дурацкую плату. Для меня вообще работа с любым трассировщиком и рисование плат — мучение. Ненавижу эту работу. Если бы можно было получить плату просто нарисовав блоки, которые мне нужны, я бы так и делал. А пока самый простой способ — именно такой — взять процессорный модуль и сделать к нему «шилд». Это быстрее и проще. А по моему времени — еще и дешевле. Вот когда будет на девайс спрос, тогда и сделаем все на одной плате, а для небольших проектов и экспериментов — самое оно.
Профессиональных разработчиков в расчет вообще не беру. Они могут себе позволить и мучаться с KEIL и IAR и заказывать платы в резоните и поддерживать зоопарк МК. Это их хлеб.
мне нужно просто, дешево и удобно.
Профессиональных разработчиков в расчет вообще не беру. Они могут себе позволить и мучаться с KEIL и IAR и заказывать платы в резоните и поддерживать зоопарк МК. Это их хлеб.
мне нужно просто, дешево и удобно.
Профессиональных разработчиков в расчет вообще не беру. Они могут себе позволить и мучаться с KEIL и IAR и заказывать платы в резоните и поддерживать зоопарк МК. Это их хлеб.
Зоопарк МК, профессиональные разработчики держать не любят, это я вам как профессиональный разработчик говорю.
Тем более. Так что вопли о том, что есть же море разных уникальных плат для меня выглядит странно — учить что-то, чтобы использовать в одном проекте? нафиг.
Я уже прошел то время, когда каждая железка вызывала восторг. Сейчас от железок мне нужна простота, надежность, дешевизна и гибкость. и желательна унификация. Почти все из этого списка я нашел. Не в идеале, но уже сносно.
Я уже прошел то время, когда каждая железка вызывала восторг. Сейчас от железок мне нужна простота, надежность, дешевизна и гибкость. и желательна унификация. Почти все из этого списка я нашел. Не в идеале, но уже сносно.
И какая вам разница, вести несколько дорожек в «шилде» к этому модулю, или к самому контроллеру?
Разница достаточно большая, если вас этот ответ устроит.
Нет, не устроит, ответьте конкретнее.
Если уж стали изготавливать плату (или откуда возьмется «шилд»?), то в чем такая уж «достаточно большая разница»?
В шаге между выводами?
Тех, кто добрался до кастомной платы, обычно это не останавливает. А если проект закончился на макетке, то не пугает «мусор» на отладочных.
Если уж стали изготавливать плату (или откуда возьмется «шилд»?), то в чем такая уж «достаточно большая разница»?
В шаге между выводами?
Тех, кто добрался до кастомной платы, обычно это не останавливает. А если проект закончился на макетке, то не пугает «мусор» на отладочных.
Как вы не поймете, что мусор на отладочных не пугает, он просто занимает место. Там куда влезет модуль, нет необходимости травить плату, но туда не поместится отладка.
И вот когда не влазит модуль, вот тогда нужно травить-паять.
Соответственно если модуль маленький, то случаев «травить-паять» становится еще меньше.
Добавлю, что в посте не отладочная плата, а именно процессорный модуль. Он сам ничего не умеет.
Отладочные платы позволяют отлаживать код без внешнего обвеса, а которые не позволяют — это процессорные модули.
И вот когда не влазит модуль, вот тогда нужно травить-паять.
Соответственно если модуль маленький, то случаев «травить-паять» становится еще меньше.
Добавлю, что в посте не отладочная плата, а именно процессорный модуль. Он сам ничего не умеет.
Отладочные платы позволяют отлаживать код без внешнего обвеса, а которые не позволяют — это процессорные модули.
Модуль это или отладочная плата вопрос спорный, границы размыты. Если мне требуется USB-устройство, я смогу отладить на этой плате код без внешнего обвеса, например.
А хостовую плату вы откуда берете тогда? И все остальное, чем модуль этот управляет?
А хостовую плату вы откуда берете тогда? И все остальное, чем модуль этот управляет?
Хостовая плата делается под задачу. Часто это просто кусок FR4 с вырезанными ножом или гравером дорожками.
Все остальное это что?
У меня, например, часто это вские оптосиммисторы, которые подключаются натурально проводами и болтиками, и на плату не паяются.
Все остальное это что?
У меня, например, часто это вские оптосиммисторы, которые подключаются натурально проводами и болтиками, и на плату не паяются.
Ага. И все остальные компоненты на хостовой плате имеют такой шаг и ширину выводов, что можно плату вырезать ножом? И все упирается только в сам STM?
Ну поздравляю, если у вас такие задачи «часто», то у вас уникальное производство, для вас эти модули в самом деле имеют смысл.
Ну поздравляю, если у вас такие задачи «часто», то у вас уникальное производство, для вас эти модули в самом деле имеют смысл.
Шаг стандартный для выводных компонентов — 2.54
Это естественно не для серийного производства изделий, а для технологических нужд.
Серийное производство у меня основано на простейшей продукции Ti и Microchip.
Подобное как в посте изделие в серийное устройство я бы не поставил по нескольким причинам.
Это естественно не для серийного производства изделий, а для технологических нужд.
Серийное производство у меня основано на простейшей продукции Ti и Microchip.
Подобное как в посте изделие в серийное устройство я бы не поставил по нескольким причинам.
Я понимаю, просто сейчас далеко не все можно найти в выводном корпусе. И далеко не всегда по требованиям пройдет плата, вырезанная ножом. На моей практике это редкость. Обычно заказчики за каждый миллиметр бьются, там не до ножа, даже TQFP вместо QFN не поставить.
Не всегда. Я же не говорю что всегда надо делать так как я.
Я и сам делаю печатные платы, когда этого требуют обстоятельства, но вот когда обстоятельства этого не требуют, предпочитаю экономить время.
Я и сам делаю печатные платы, когда этого требуют обстоятельства, но вот когда обстоятельства этого не требуют, предпочитаю экономить время.
Я тоже, просто не сталкивался с возможностью экономить время на мелочи типа TQFP.
А вот с тяжеловесными процами — это да, сам уже сколько вот разные модули рассматриваю. И, кстати, вот там-то точно прямо зло берет — китайцы делают на гигагерцовом проце, с гигом оперативки миникомпьютер размером 85х27 — при том что там еще левая фигня типа HDMI, разъемы, прочая дрянь.
А самый близкий по размерам девелоперский модуль оказывается сильно хреновее. Вот почему не сделают дев.модули на той же базе, на которой китайцы свои мини-компы клепают?
А вот с тяжеловесными процами — это да, сам уже сколько вот разные модули рассматриваю. И, кстати, вот там-то точно прямо зло берет — китайцы делают на гигагерцовом проце, с гигом оперативки миникомпьютер размером 85х27 — при том что там еще левая фигня типа HDMI, разъемы, прочая дрянь.
А самый близкий по размерам девелоперский модуль оказывается сильно хреновее. Вот почему не сделают дев.модули на той же базе, на которой китайцы свои мини-компы клепают?
Мини-компы для широкой публики и цену свою имеют благодаря массовости.
Отладочные платы же — товар штучный.
Тут прямая аналогия с измерительной техникой, например.
Ведь осциллограф Agillent на 500MHz стоит 10 килобаксов не потому, что там себестоимость 8, а потому что покупают их один в неделю(грубо говоря).
Отладочные платы же — товар штучный.
Тут прямая аналогия с измерительной техникой, например.
Ведь осциллограф Agillent на 500MHz стоит 10 килобаксов не потому, что там себестоимость 8, а потому что покупают их один в неделю(грубо говоря).
Я не о стоимости даже, а о наличии.
Стоимость это уже второй вопрос, но их просто нет.
Стоимость это уже второй вопрос, но их просто нет.
Их потому и нет, что никто их не покупает так, как андроидобалалайки.
Дык нет, почему андроид-то? На них вон дебиан спокойно встает.
Покупают аналогичные, но хуже по всем характеристикам. Вот и интересно, почему никак не сделают на этой схематике (пусть даже по цене больше, чем китайские микрокомпы)
Покупают аналогичные, но хуже по всем характеристикам. Вот и интересно, почему никак не сделают на этой схематике (пусть даже по цене больше, чем китайские микрокомпы)
Потому что продаются они, как правило, с предустановленным андроидом.
При чем без подписания NDA, и договора поставки хотя бы на 100000 в год, вы даже пдфку на их проц адекватную не найдете. Производители делают девборды только из того, что доступно в штучных количествах. То есть 100 штук топовых квалькомов или топовых омапов вы никогда и ни при каких условиях у производителя не купите. Поэтому в девборде смысла нет.
А современные АРМы это как современные видюхи. Через год про них забывают, потому что появляются новые. Потреблядство достигло даже эмбеддинга. Благодаря ему, вы не найдете скоро документации по нынешним младшим кортексам, да и купить не сможете. В отличие от того же PIC16F84A, который хоть и по невменяемой цене, все еще доступен для покупки прямо у производителя, т.е. до сих пор производится.
При чем без подписания NDA, и договора поставки хотя бы на 100000 в год, вы даже пдфку на их проц адекватную не найдете. Производители делают девборды только из того, что доступно в штучных количествах. То есть 100 штук топовых квалькомов или топовых омапов вы никогда и ни при каких условиях у производителя не купите. Поэтому в девборде смысла нет.
А современные АРМы это как современные видюхи. Через год про них забывают, потому что появляются новые. Потреблядство достигло даже эмбеддинга. Благодаря ему, вы не найдете скоро документации по нынешним младшим кортексам, да и купить не сможете. В отличие от того же PIC16F84A, который хоть и по невменяемой цене, все еще доступен для покупки прямо у производителя, т.е. до сих пор производится.
Ну вот конкретно с Allwinner вроде как раз все полегче. Я потому и говорю — есть на нем опенсорсная CubieBoard же. Доки есть, официально. Линукс портирован официально, самими разработчиками процессора.
Но почему-то нормальных процессорных модулей нет! А КубиБоард — это ардуиноподобная плата, не то что нужно. Если бы сделали проц. модуль на нем в формфакторе того китайского миникомпьютера (а то и меньше, там же большую часть можно выкинут), цены бы ему не было.
Но почему-то нормальных процессорных модулей нет! А КубиБоард — это ардуиноподобная плата, не то что нужно. Если бы сделали проц. модуль на нем в формфакторе того китайского миникомпьютера (а то и меньше, там же большую часть можно выкинут), цены бы ему не было.
Согласен, к счастью, на этой плате ее можно просто отпилить :) под ней ничего ценного нет, так что просто плата станет короче :)
Надеюсь, вы имеете в виду SWD, как альтернативу, а не прошивку через встроенный уартовский загрузчик.
Кстати, SWD действительно полноценная альтернатива JTAG — и по скорости и по функционалу отладки. И это тоже плюс STM32 на мой взгляд.
Тот же TI со своим странным ICDI мне нравится куда меньше.
Тот же TI со своим странным ICDI мне нравится куда меньше.
Ну я работаю в режиме SWD, пока не сталкивался ни с какими заморочками, да.
Правда, насколько я знаю, JTAG-то позволяет работать с большим количеством устройств, подключенных к одному и тому же отладочному интерфейсу, так что, скорее всего, тут SWD не поможет.
Правда, насколько я знаю, JTAG-то позволяет работать с большим количеством устройств, подключенных к одному и тому же отладочному интерфейсу, так что, скорее всего, тут SWD не поможет.
STM тут не при чем, SWD это стандарт ARM, покажите хотя бы один Cortex M без него.
Жтаг все же чуть чуть побыстрей будет.
А пихают его везде не только ради отладки, а еще ради граничного сканирования. Собственно то ради чего он и был задуман.
А пихают его везде не только ради отладки, а еще ради граничного сканирования. Собственно то ради чего он и был задуман.
Не судите по себе — полчеловека на сотню радиолюбителей.
JTAG это deprecated. SWD его полноценная замена. Если вы не программируете под ARM7/9 можно с ним и не начинать разбираться.
Но если вы занимаетесь embedded linux, то с прошивкой бута через jtag для ARM9 рано или поздно Вам придется столкнуться.
JTAG это deprecated. SWD его полноценная замена. Если вы не программируете под ARM7/9 можно с ним и не начинать разбираться.
Но если вы занимаетесь embedded linux, то с прошивкой бута через jtag для ARM9 рано или поздно Вам придется столкнуться.
SWD не поддерживает граничное сканирование и не может быть заменой JTAG для JTAG отладка это вообще побочная фича. Ее может и не быть.
Хотелось бы узнать, а как Вы на практике это используете?
Предположу, что проверка плат на производстве.
Я никак не использую, у меня нет крупносерийных девайсов Где требовались бы массовые автоматические тесты.
Хорошо, тогда в теории. Вы посылаете EXTEST последовательность и снимаете ее на внешнем устройстве, или наоборот, принимаете INTEST. Так, или я чего-то не знаю?
жтагом можно поднять ногу на одной микрухе, а через другую замерить уровень на общей дорожке между ними. высислив, например, непропай. Все жтаг устройства соединяются цепью.
Я про это и говорил.
Все это можно сделать
а) в простом случае — используя SWD/DAP просто подергав ногами
б) зашить тестовую прошивку через SWD и получать данные с помощью протокола SWD/ITM
SWD также позволяет подключать несколько устройств к одной шине.
А используя SWD/ITM можно вообще отказаться от уарта в отладочных целях.
Согласны с первым тезисом насчет deprecated? :)
Все это можно сделать
а) в простом случае — используя SWD/DAP просто подергав ногами
б) зашить тестовую прошивку через SWD и получать данные с помощью протокола SWD/ITM
SWD также позволяет подключать несколько устройств к одной шине.
А используя SWD/ITM можно вообще отказаться от уарта в отладочных целях.
Согласны с первым тезисом насчет deprecated? :)
swd есть только в кортексах, а жтаг это стандарт и бывает много где. Не только в микроконтроллерах и процах, но и в ацп может стоять или в какой спец шняге.
Сейчас — да. В промышленности сейчас ARM7/9 еще более чем распространены, хотя архитектура уже устарела.
Стандарт — тут не поспоришь.
Тем не менее ARM позиционирует SWD как полноценную замену JTAG.
www.arm.com/products/system-ip/debug-trace/coresight-soc-components/serial-wire-debug.php
В теории я не вижу проблем реализовать boundary scan с использованием SWD.
На практике, я не видел чтобы кто-то использовал JTAG boundary scan на cortex m. К сожалению, моя практика тоже ограничена мелкосерийкой.
Стандарт — тут не поспоришь.
Тем не менее ARM позиционирует SWD как полноценную замену JTAG.
www.arm.com/products/system-ip/debug-trace/coresight-soc-components/serial-wire-debug.php
В теории я не вижу проблем реализовать boundary scan с использованием SWD.
На практике, я не видел чтобы кто-то использовал JTAG boundary scan на cortex m. К сожалению, моя практика тоже ограничена мелкосерийкой.
В теории просто этот SWD должны поддерживать не только ARM, а вообще все. В том числе и плисы и всякие кастомные SOC и много кто еще. Чтобы их можно было цепочкой включить друг за друга и отлаживать. Либо вешать дальнейшую цепь и эмулировать жтаг программно, что будет лютый геморрой т.к. эту вещь надо будет как то подружить с промышленными системами тестирования.
А для отладки на чипе да, можно везде и всюду SWD юзать.
А для отладки на чипе да, можно везде и всюду SWD юзать.
Не надо уходить от ответа, Вы согласны, что утверждение:
> SWD не поддерживает граничное сканирование
неверно?
> SWD не поддерживает граничное сканирование
неверно?
В теории граничное сканирование поддерживает даже уарт и что угодно. На практике вы этот SWD не сможете вписать в общую цепь с другими JTAG устройствами на плате, а значит для граничного сканирования он не пригоден.
> В теории граничное сканирование поддерживает даже уарт и что угодно
Т.е. расплывчато, но признали неправоту. А на практике:
> Я никак не использую
Я не буду говорить, как это называется ;)
Т.е. расплывчато, но признали неправоту. А на практике:
> Я никак не использую
Я не буду говорить, как это называется ;)
Неправоту в чем? в том что через SWD можно дергать ножками и как то попытаться эмулировать TAP контроллер JTAG? Можно. И через UART можно попробовать и через SPI или I2C или любой другой интерфейс залив туда соответствующую прошивку. И что?
Граничное сканирование это не дерганье ножками, а целый комплекс стандартных технических решений позволяющий проверить всю плату единым процессом, стандартным софтом и стандартным аппаратным обеспечением. Тем арсеналом который имеет в наличии любой крупный производитель оборудования. Без каких либо костылей, эмуляций и прочих выпердонов.
Граничное сканирование это не дерганье ножками, а целый комплекс стандартных технических решений позволяющий проверить всю плату единым процессом, стандартным софтом и стандартным аппаратным обеспечением. Тем арсеналом который имеет в наличии любой крупный производитель оборудования. Без каких либо костылей, эмуляций и прочих выпердонов.
Где тут ARM9?
Камон, ребят хватит уже статей «смотрите, кроме ардуино есть плата X» и больше ничего.
Да и инфы по stm32 уже полным полно в сети, есть даже готовые курсы от GPIO до подключения дисплеев.
Возможно лучше дополнить эти курсы новое периферией?
Или описать что-то еще интересно?
Есть же PSoC от сайпрес — куда более интересная штука для хоббистов да и чисто для статьи, тк совсем другой принцип построения системы: периферия набирается из стандартных блоков, из них можно сделать таймер, а можно SPI, ОУ или компаратор, все в графической форме в бесплатной IDE(которую кстати делают на украине), по сути это ядро + аналог + плис + готовые IP ядра периферии. Ядра постоянно выпускают, представьте: на ваш старый МК можно добавить новую периферию! Или сделать что-то с 20UART или еще что, можно самому писать блоки периферии. На каждый блок отдельный User Manual что супер удобно.
Можно переконфигурировать МК в процессе исполнения кода, сначала на ногах таймер а потом последовательный интерфейс, а потом с тех же ног выдает мощный ток, затем это сенсорная клавиша -> обошлись 16 выводным корпусом.
Есть уникальные МК типа Energy Micro, которые изначально затачивали под супер малое потребление
Действительно низкое энергопотребление, похоже вся периферия разрабатывалась с нуля и реально работает на супер маленьких токах.
Обалденная документация, примеры, работающие из коробки, хорошо документированные связные билиотеки и лучшие отладки из тех что я щупал: помимо стандартного встроенного отладчика есть возможность мерить ток потребления(до нА) и рисовать графики в реальном времени, при этом видя все переходы и копить статистику с автоматическим подсчетом энергопотребления каждой функции в джоулях. Очень дружественный форум с кучей FAEшников и энтузиастов.
Infineon выпустил очень специфичную серию МК на Cortex M0 под power conversion, lighting и motor control.
фишки: шина и периферия работает на удвоенной частоте ядра, очень быстрая флеш, есть варианты мк с 16К флеша 16К ОЗУ, GPIO до 50мА, есть варианты с сопроцессором(деление + CORDIC) и вся эта прелесть в SIOC корпусах.
Столько интересного вокруг ведь елки палки.
Да и инфы по stm32 уже полным полно в сети, есть даже готовые курсы от GPIO до подключения дисплеев.
Возможно лучше дополнить эти курсы новое периферией?
Или описать что-то еще интересно?
Есть же PSoC от сайпрес — куда более интересная штука для хоббистов да и чисто для статьи, тк совсем другой принцип построения системы: периферия набирается из стандартных блоков, из них можно сделать таймер, а можно SPI, ОУ или компаратор, все в графической форме в бесплатной IDE(которую кстати делают на украине), по сути это ядро + аналог + плис + готовые IP ядра периферии. Ядра постоянно выпускают, представьте: на ваш старый МК можно добавить новую периферию! Или сделать что-то с 20UART или еще что, можно самому писать блоки периферии. На каждый блок отдельный User Manual что супер удобно.
Можно переконфигурировать МК в процессе исполнения кода, сначала на ногах таймер а потом последовательный интерфейс, а потом с тех же ног выдает мощный ток, затем это сенсорная клавиша -> обошлись 16 выводным корпусом.
Есть уникальные МК типа Energy Micro, которые изначально затачивали под супер малое потребление
Действительно низкое энергопотребление, похоже вся периферия разрабатывалась с нуля и реально работает на супер маленьких токах.
Обалденная документация, примеры, работающие из коробки, хорошо документированные связные билиотеки и лучшие отладки из тех что я щупал: помимо стандартного встроенного отладчика есть возможность мерить ток потребления(до нА) и рисовать графики в реальном времени, при этом видя все переходы и копить статистику с автоматическим подсчетом энергопотребления каждой функции в джоулях. Очень дружественный форум с кучей FAEшников и энтузиастов.
Infineon выпустил очень специфичную серию МК на Cortex M0 под power conversion, lighting и motor control.
фишки: шина и периферия работает на удвоенной частоте ядра, очень быстрая флеш, есть варианты мк с 16К флеша 16К ОЗУ, GPIO до 50мА, есть варианты с сопроцессором(деление + CORDIC) и вся эта прелесть в SIOC корпусах.
Столько интересного вокруг ведь елки палки.
А есть что готовое к тому, чтобы быстро подключить большой (7") экран и чтобы памяти хватило на два буфера?
Не по конской цене и доступное?
Не по конской цене и доступное?
SoMы разные с линуксом. Можно до 2000р уложиться.
Какое разрешение экрана, сколько бит цвет?
Отладочная плата это готовое?
Какая нужна цена?
Нужен ли линукс?
Отладочная плата это готовое?
Какая нужна цена?
Нужен ли линукс?
Экран — что-то типа 800х600 точек, 16М цветов много, но 256 — мало.
Лучше если минимальная отладочная плата — распаянный процессор с необходимым и разъем. Или даже просто МК, но так, чтобы дополнительные элементы не пришлось искать по всему миру.
Без линукса, только RTOS, только хардкор.
Лучше если минимальная отладочная плата — распаянный процессор с необходимым и разъем. Или даже просто МК, но так, чтобы дополнительные элементы не пришлось искать по всему миру.
Без линукса, только RTOS, только хардкор.
У Starterkit-a не смотрели? Например такую
Да, плата ниже вполне подойдет, но есть одно но:
а найдете ли вы дисплей с RGB интерфейсом такого разрешения? Это вопрос.
Да и обновление картинки сожрет все процессорное время.
В этом году Renesas выпустил Cortex A8 в LQFP с 10МБ(мегабайтами)!!! ОЗУ на борту, думаю модули скоро появятся, хотя может и нет это ж lqfp :)
Freescale выпустил Cortex A5 + M4. Можно будет разнести GUI и real time по разным ядрам.
С ним будет очень классная платка, но пока предзаказ только для Америки:(
phytec.com/products/single-board-computers/
Есть ОСРВ и графическая била бесплатно в исходниках
Если хочется прям сейчас то мне кажется стоит выбрать графическую библиотеку и по ней уже производителя.
а найдете ли вы дисплей с RGB интерфейсом такого разрешения? Это вопрос.
Да и обновление картинки сожрет все процессорное время.
В этом году Renesas выпустил Cortex A8 в LQFP с 10МБ(мегабайтами)!!! ОЗУ на борту, думаю модули скоро появятся, хотя может и нет это ж lqfp :)
Freescale выпустил Cortex A5 + M4. Можно будет разнести GUI и real time по разным ядрам.
С ним будет очень классная платка, но пока предзаказ только для Америки:(
phytec.com/products/single-board-computers/
Есть ОСРВ и графическая била бесплатно в исходниках
Если хочется прям сейчас то мне кажется стоит выбрать графическую библиотеку и по ней уже производителя.
Дисплеи есть у китайцев. Конечно осознаю, что обновление картинки съест большую часть времени, но на то и нацеливаюсь — хочу красиво вырисовывать приходящие извне готовые данные.
Благодарю за ответы!
Благодарю за ответы!
>обновление картинки съест большую часть времени
Дык DMA вам в помощь.
Дык DMA вам в помощь.
дык во фрейм-буфер кто-то писать должен все равно:)
Если картинка статичная то да, а вот ее обновление будет лихо подъедать ресурсы, а если вы курсор или слои с хромокием захотите и контроллер дисплея этого не поддерживает, то придется туго.
Если картинка статичная то да, а вот ее обновление будет лихо подъедать ресурсы, а если вы курсор или слои с хромокием захотите и контроллер дисплея этого не поддерживает, то придется туго.
А, это да) Правда, если там окошки/кнопочки, то еще не так страшно — их элементы во флешке сохранить и натравливать DMA на нужные фрагменты. Или если там тайлы, как в NES) Тайлы DMAшкой выводить одно удовольствие)
А вообще, в таком случае, я бы выделил отдельный контроллер на графику, наверное — если дисплейный тупой, как у дешевых китайских. Ему бы шли высокоуровневые команды типа «нарисовать окно», а он уж пусть ими ворочает, не смешивая с бизнес-логикой.
А вообще, в таком случае, я бы выделил отдельный контроллер на графику, наверное — если дисплейный тупой, как у дешевых китайских. Ему бы шли высокоуровневые команды типа «нарисовать окно», а он уж пусть ими ворочает, не смешивая с бизнес-логикой.
Ну да, либо хотя бы РТОС разделить задачки по приоритету, если отзывчивость особо не нужна.
А как с тайлами реализовывается?
Выделяем 1 канал DMA на переброс фреймбуфера.
Выделяем 2 канал DMA на формирование фреймбуфера и натравливаем его на определенные заранее готовые картинки и перекидывание их в определенные области ФБ?
Интересный метод, не думал о таком.
Как я понимаю чем больше размеры тайлов и чем их меньше тем выгоднее становится его использовать.
А есть какие-нибудь примерчики реализации(видео или картинка)?
А как с тайлами реализовывается?
Выделяем 1 канал DMA на переброс фреймбуфера.
Выделяем 2 канал DMA на формирование фреймбуфера и натравливаем его на определенные заранее готовые картинки и перекидывание их в определенные области ФБ?
Интересный метод, не думал о таком.
Как я понимаю чем больше размеры тайлов и чем их меньше тем выгоднее становится его использовать.
А есть какие-нибудь примерчики реализации(видео или картинка)?
Особенно классно смотрится на тех МК, где настройка DMA не через регистры а через определенные области озу, поидее мы переменные с местоположением основной движущейся ерунды типа курсора можем прям в них хранить.
Это если есть фреймбуфер)
Я в свое время работал без него (не хватает у STMки оперативки на 320х240х16), поэтому просто храним во флешке тайлы и карту вида
1 1 2 1 3
1 1 1 1 1
…
С номерами тайлов.
Ну и все, собственно — пускаем DMA, сказав ему выводить тайл address[map[0][0]] в положение x*tileX,y*tileY, x=0, y=0.
А в прерывании по окончании передачи DMA просто делаем x++ (ну или, соответственно, y++, если дошли до конца строки), и задаем новый адрес address[map[x][y]] источника. Вот и все. Никакого фреймбуфера не нужно.
Примеров у меня не сохранилось, но реализация тривиальная.
Есть вот такое видео у меня, не совсем тайлы, но тоже похожая реализация, потому что, опять-таки, фреймбуфера у меня не было, чтоб хранить весь фрактал, поэтому плазма генерилась мелкими кусочками, которые кидались на DMA, пока генерится следующий.
Я в свое время работал без него (не хватает у STMки оперативки на 320х240х16), поэтому просто храним во флешке тайлы и карту вида
1 1 2 1 3
1 1 1 1 1
…
С номерами тайлов.
Ну и все, собственно — пускаем DMA, сказав ему выводить тайл address[map[0][0]] в положение x*tileX,y*tileY, x=0, y=0.
А в прерывании по окончании передачи DMA просто делаем x++ (ну или, соответственно, y++, если дошли до конца строки), и задаем новый адрес address[map[x][y]] источника. Вот и все. Никакого фреймбуфера не нужно.
Примеров у меня не сохранилось, но реализация тривиальная.
Есть вот такое видео у меня, не совсем тайлы, но тоже похожая реализация, потому что, опять-таки, фреймбуфера у меня не было, чтоб хранить весь фрактал, поэтому плазма генерилась мелкими кусочками, которые кидались на DMA, пока генерится следующий.
Если linux устроит, то Tiny210v2, например.
RTOS тоже можно, но сложнее.
RTOS тоже можно, но сложнее.
Кстати, покажите мне такой курс. Желательно, чтобы он был не на KEIL или IAR или TRUE Studio. Потому что я рассматриваю эту плату как отличный девайс для хобби и домашних проектов, покупать и ставить монстроидальные и устаревшие KEIL или IAR нет желания и смысла.
Arduino выигрывает в популярности тем, что она имеет простую IDE и возможность развития. Пока не сделаем такой же простой способ начать работать с STM32 ни фига не получится. Лично я перелопатил кучу статей по настройке Eclipse и других IDE. И везде проект создается полчаса, вечно что-то надо считать, постоянно забываю какие-то моменты, не компилится сходу. Мне это надоело, я нашел IDE, в которой проект создается визардом готовый к применению, надо только нажать F7 и он скомпилен, F6 и он прошит в девайс. Почти как в Arduino. И кода надо десяток строчек всего.
Еще один немаловажный момент — эта плата ДЕШЕВАЯ. Очень дешевая. 300 рублей. И отладчик за 20-25 баксов купить можно, если нужен. Это важно. Для многих важно.
Мне нравится в STM32 еще и то, что изменения в коде минимальные. Заменил девайс на другой из серии и проект работает практически без изменений. Это круто. Ведь есть в серии и дешевые F100 и с офигенным функционалом F103/105/107. А если надо есть и F3/F4 с DSP, FPU и кучей фич. И все это в рамках одного производителя, одного инструментария, одной архитектуры. Никакого зверинца. Изучать нужно куда меньше. Бери и пользуйся. Периферия зависит от семейства, разводка в пределах одного корпуса будет одна.
Я вообще не люблю разводить зоопарк. У меня сейчас для всех проектов хватает двух семейств. AVR Atmega 168/328 и STM32F1-F4
Arduino выигрывает в популярности тем, что она имеет простую IDE и возможность развития. Пока не сделаем такой же простой способ начать работать с STM32 ни фига не получится. Лично я перелопатил кучу статей по настройке Eclipse и других IDE. И везде проект создается полчаса, вечно что-то надо считать, постоянно забываю какие-то моменты, не компилится сходу. Мне это надоело, я нашел IDE, в которой проект создается визардом готовый к применению, надо только нажать F7 и он скомпилен, F6 и он прошит в девайс. Почти как в Arduino. И кода надо десяток строчек всего.
Еще один немаловажный момент — эта плата ДЕШЕВАЯ. Очень дешевая. 300 рублей. И отладчик за 20-25 баксов купить можно, если нужен. Это важно. Для многих важно.
Мне нравится в STM32 еще и то, что изменения в коде минимальные. Заменил девайс на другой из серии и проект работает практически без изменений. Это круто. Ведь есть в серии и дешевые F100 и с офигенным функционалом F103/105/107. А если надо есть и F3/F4 с DSP, FPU и кучей фич. И все это в рамках одного производителя, одного инструментария, одной архитектуры. Никакого зверинца. Изучать нужно куда меньше. Бери и пользуйся. Периферия зависит от семейства, разводка в пределах одного корпуса будет одна.
Я вообще не люблю разводить зоопарк. У меня сейчас для всех проектов хватает двух семейств. AVR Atmega 168/328 и STM32F1-F4
Стоп, как раз у STM одна из наиболее сегментированных линеек. Прыжки с F1x на F2/3/4 не так просты, как у TI, EnergyMicro, Futjitsu Infineon и Freescale у двух последних вообще есть настройка периферии и генерация нужных библ в графическом виде, тупо галочки ставим и выбираем опции вот классный блог на эту тему mcuoneclipse.com.
По поводу курсов
microtechnics.ru/
easyelectronics.ru/arm-uchebnyj-kurs-taktovyj-generator-stm32.html
ziblog.ru/2011/01/11/pervyiy-start-s-stm32-discovery-chast-7-ndash-sistema-taktirovaniya-rtc-taymer.html
Насчет IDE согласен полностью из коробки мало что работает.
Имхо доя новичков все же лучше выбрать IAR, для него всегда много работающих примеров и много проблем разжевано в интернете. Кикстарт версии в 32К хватит чтобы попробовать наверное всю периферию кроме USB, графических дислпейчиков и Ethernet. А дальше можно либо настроить под себя Eclipse с GCC, либо Cocoox. Я например дома пользуюсь Em::Blocks — очень нравится: быстрая, настраиваемая(все горячи клавишы заточил под себя) + плагины(оставил doxygen — геренирую html доки из комментариев, офигенно), основана на CodeBlocks. Опять же проект из IAR в нее перенести проще некуда, достаточно помучаться один раз с рыбой, подсунуть стартап файл и билиотечки и потом тупо перенести все исходники в проект, нажать Compile и почистить ошибки. КМК это куда проще чем разобрать банальные CDC/HID класс.
По поводу курсов
microtechnics.ru/
easyelectronics.ru/arm-uchebnyj-kurs-taktovyj-generator-stm32.html
ziblog.ru/2011/01/11/pervyiy-start-s-stm32-discovery-chast-7-ndash-sistema-taktirovaniya-rtc-taymer.html
Насчет IDE согласен полностью из коробки мало что работает.
Имхо доя новичков все же лучше выбрать IAR, для него всегда много работающих примеров и много проблем разжевано в интернете. Кикстарт версии в 32К хватит чтобы попробовать наверное всю периферию кроме USB, графических дислпейчиков и Ethernet. А дальше можно либо настроить под себя Eclipse с GCC, либо Cocoox. Я например дома пользуюсь Em::Blocks — очень нравится: быстрая, настраиваемая(все горячи клавишы заточил под себя) + плагины(оставил doxygen — геренирую html доки из комментариев, офигенно), основана на CodeBlocks. Опять же проект из IAR в нее перенести проще некуда, достаточно помучаться один раз с рыбой, подсунуть стартап файл и билиотечки и потом тупо перенести все исходники в проект, нажать Compile и почистить ошибки. КМК это куда проще чем разобрать банальные CDC/HID класс.
Так здесь все то же самое. F103V например и F407V становятся на одну и ту же плату.
F1 и F2 — это Cortex M3
F3 и F4 — это Cortex M4
ядро вообще разное.
Насчет графической конфигурялки то же самое MicroXplorer называется:
Выбираем функции, режимы, она генерит файлы настройки и инициализации периферии.
Вдобавок еще и поможет подобрать МК из всех линеек, которые имеют заданные функции. С фильтрами по корпусам, сериям и подсериям
Курс на easyelectronics читал полностью. Во-первых он под KEIL, во вторых ни фига не для начинающих. Даже реализовав не один проект на AVR я не смог сходу въехать.
Теоретический материал там неплохо дан, но мало и далеко не с начала и не до конца, так, основы и некоторые моменты. Для тех кому ногами подрыгать, в основном. В целом почерпнул для себя немало, но этого недостаточно.
IAR идет лесом сразу же — отстойнейший редактор, плюс платный.
F1 и F2 — это Cortex M3
F3 и F4 — это Cortex M4
ядро вообще разное.
Насчет графической конфигурялки то же самое MicroXplorer называется:
Выбираем функции, режимы, она генерит файлы настройки и инициализации периферии.
Вдобавок еще и поможет подобрать МК из всех линеек, которые имеют заданные функции. С фильтрами по корпусам, сериям и подсериям
Курс на easyelectronics читал полностью. Во-первых он под KEIL, во вторых ни фига не для начинающих. Даже реализовав не один проект на AVR я не смог сходу въехать.
Теоретический материал там неплохо дан, но мало и далеко не с начала и не до конца, так, основы и некоторые моменты. Для тех кому ногами подрыгать, в основном. В целом почерпнул для себя немало, но этого недостаточно.
IAR идет лесом сразу же — отстойнейший редактор, плюс платный.
M3 это подмножества ядра М4, совместимость вверх сохраняется бинарная, если вы пишете на си то и того проще.
А вот разные библиотеки периферии с разным API и в принципе разная периферия это не есть хорошо без веских на то причин.
По поводу IAR -это вы глупости говорите, да есть проблемы но это одна из знаменитейших и наиболее используемых сред в профессиональной разработке, я думаю это не с проста.
Они первые написали СИ компилятор для 8051, совместно с ними разрабатывалась архитектура AVR, у них самый лучший компилятор, на данный момент все производители меряются бенчмарками теста скомпилиронного в IARе, к тому же в отличие от Keil он поддерживает огромное количество архитектур. Все примеры приличных производителей у меня работали из коробки без настройки.
Эклипс — да штука универсальная, поэтому настройки очень много.
По поводу микроэксплорера — начинание отличное, но надо еще очень долго пились. Все очень примитивно: раскидать по ногам, включить в самом простом режиме. В инициализаторах от инфинеон, фрискейл и ренесас это интегрированно в собственные(!) IDE(дада, там все работает из коробки) и просто миллион опций, покрывающих 90% функционала периферии, остальное покрыто библами. В них можно инициализировать DMA, Ethernet или DRAM контроллеры, можно тупо включить USB в режиме device выбрать класс CDC и пользоваться им тупо как уартом: sendstring()/getstring() под капот вообще не лезть, при инициализации таймеров можно задать периоды в человеческих величинах(КГц/секунды) все делители он посчитает сам и если где-то будет конфликт(вы забыли включить что-то) то все это будет снабжено подсказкой.
А вот разные библиотеки периферии с разным API и в принципе разная периферия это не есть хорошо без веских на то причин.
По поводу IAR -это вы глупости говорите, да есть проблемы но это одна из знаменитейших и наиболее используемых сред в профессиональной разработке, я думаю это не с проста.
Они первые написали СИ компилятор для 8051, совместно с ними разрабатывалась архитектура AVR, у них самый лучший компилятор, на данный момент все производители меряются бенчмарками теста скомпилиронного в IARе, к тому же в отличие от Keil он поддерживает огромное количество архитектур. Все примеры приличных производителей у меня работали из коробки без настройки.
Эклипс — да штука универсальная, поэтому настройки очень много.
По поводу микроэксплорера — начинание отличное, но надо еще очень долго пились. Все очень примитивно: раскидать по ногам, включить в самом простом режиме. В инициализаторах от инфинеон, фрискейл и ренесас это интегрированно в собственные(!) IDE(дада, там все работает из коробки) и просто миллион опций, покрывающих 90% функционала периферии, остальное покрыто библами. В них можно инициализировать DMA, Ethernet или DRAM контроллеры, можно тупо включить USB в режиме device выбрать класс CDC и пользоваться им тупо как уартом: sendstring()/getstring() под капот вообще не лезть, при инициализации таймеров можно задать периоды в человеческих величинах(КГц/секунды) все делители он посчитает сам и если где-то будет конфликт(вы забыли включить что-то) то все это будет снабжено подсказкой.
IAR — это не проблемы — это полностью устаревшая IDE. Если у вас проект из 3х файлов и имена переменных вы помните наизусть, это не проблема. Если же проект посложнее — он неконкурентент даже с тормознутым Eclipse.
Единственное достоинство IAR — это его компилер. В остальном среда крайне неудобная. Особенно когда есть с чем сравнить. А мне есть с чем.
В этом мире много кто был первым, но теперь в жопе. IBM был изобретателем PC, а теперь они этим даже не занимаются и правильно — получалось у них плохо, как ни крути мэйнфрейм получается и по дизайну и по цене.
Эклипс, как я уже говорил — хоть и универсальный, а удобства не добавляется даже после настройки.
Тот же CodeBlocks такой же универсальный, но работать в нем удобно с любым тулчейном. Он тоже кроссплатформенный. Компилит и С и С++, native код, а потому быстрый. Гибко настраиваемый и легкий. Ко всему еще и бесплатный.
Есть много крутых производителей, но мало кто предоставляет хороший инструментарий для хобби. Потому что ориентированы на производство, на крупных разработчиков, а не на одиночек-любителей.
Под STM32 мне удалось собрать свой инструментарий — бесплатный, открытый, достаточно удобный.
Обсуждать IAR не буду уже потому, что бесплатная версия до 32кБ, чего мне уже стало мало. А ставить крякнутый продукт и тем более писать обучающие курсы на этой основе считаю глупым и в корне неверным. Я же не обучаю программингу в Delphi. Хотя по удобству сравнимых сред ровно одна — Visual Studio и то проигрывает на мой взгляд.
Если бы сделали учебный курс для начинающих и бесплатный удобный инструментарий, у STM32 весь рынок был бы в кармане. Но пока имеем то, что имеем.
Единственное достоинство IAR — это его компилер. В остальном среда крайне неудобная. Особенно когда есть с чем сравнить. А мне есть с чем.
В этом мире много кто был первым, но теперь в жопе. IBM был изобретателем PC, а теперь они этим даже не занимаются и правильно — получалось у них плохо, как ни крути мэйнфрейм получается и по дизайну и по цене.
Эклипс, как я уже говорил — хоть и универсальный, а удобства не добавляется даже после настройки.
Тот же CodeBlocks такой же универсальный, но работать в нем удобно с любым тулчейном. Он тоже кроссплатформенный. Компилит и С и С++, native код, а потому быстрый. Гибко настраиваемый и легкий. Ко всему еще и бесплатный.
Есть много крутых производителей, но мало кто предоставляет хороший инструментарий для хобби. Потому что ориентированы на производство, на крупных разработчиков, а не на одиночек-любителей.
Под STM32 мне удалось собрать свой инструментарий — бесплатный, открытый, достаточно удобный.
Обсуждать IAR не буду уже потому, что бесплатная версия до 32кБ, чего мне уже стало мало. А ставить крякнутый продукт и тем более писать обучающие курсы на этой основе считаю глупым и в корне неверным. Я же не обучаю программингу в Delphi. Хотя по удобству сравнимых сред ровно одна — Visual Studio и то проигрывает на мой взгляд.
Если бы сделали учебный курс для начинающих и бесплатный удобный инструментарий, у STM32 весь рынок был бы в кармане. Но пока имеем то, что имеем.
Даже не знаю, как только вообще можно нахваливать что IAR, что Keil. У обоих совершенно уродские IDE и ужаснейшие компиляторы.
Компиляторы ругать не буду, не сравнивал. Но говорят, что IAR для AVR, к примеру — лучший компилер, потому что разрабатывался совместно с Atmel.
А вот IDE — полный хлам. Для 2013 года -это полный позор. где-то в 1995-1999 это еще могло прокатить.
А вот IDE — полный хлам. Для 2013 года -это полный позор. где-то в 1995-1999 это еще могло прокатить.
Да редактор кода у них помойный, IAR пробует перейти на Eclipse(но у него свои недостатки).
Но по поводу компилятора — не говорите ерунды, лучше расскажите по каким параметрам и с чем сравниваете?
По плотности и скорости кода GCC им сильно сливает.
К тому же IDE это еще и отладчик, помимо самого GDB/C-SPY есть куча полезных фич, которые в этих средах отлчично реализованы.
Но по поводу компилятора — не говорите ерунды, лучше расскажите по каким параметрам и с чем сравниваете?
По плотности и скорости кода GCC им сильно сливает.
К тому же IDE это еще и отладчик, помимо самого GDB/C-SPY есть куча полезных фич, которые в этих средах отлчично реализованы.
я тоже пользуюсь EmBlocks. Тоже настроил под себя, но нашел ее еле-еле. Перебрал вообще все доступные IDE.
Вот именно — даже перечисление уже напрягает — подсунуть то, засунуть библиотеки, перенести ихсодники, чистить еще ошибки после этого.
Это не разработка — это сплошная ерунда.
Нормальная среда работает цельно. Все работает как положено.
Я вот для себя сделал настройки в EmBlocks так, чтобы любой новый проект генерился автоматом с нужными настройками. И каждому, кто захочет этим воспользоваться, достаточно распаковать этот архив, а не придется трахаться с настройкой IAR или хуже того Eclipse — более глючного варианта, который постоянно на каждый чих нужно настраивать, а удобства так и не появляется, я не видел.
HID — ни разу не банален.тонкостей в нем вагон и маленькая тележка. Недаром одна спецификация — увесистый том.
Но один раз написав, можно решать основную задачу — двустороннего обмена с ПК очень удобно.
Вот бы еще разобраться с USB HOST на F4, чтобы подключать джойстик к девайсу.
Вот именно — даже перечисление уже напрягает — подсунуть то, засунуть библиотеки, перенести ихсодники, чистить еще ошибки после этого.
Это не разработка — это сплошная ерунда.
Нормальная среда работает цельно. Все работает как положено.
Я вот для себя сделал настройки в EmBlocks так, чтобы любой новый проект генерился автоматом с нужными настройками. И каждому, кто захочет этим воспользоваться, достаточно распаковать этот архив, а не придется трахаться с настройкой IAR или хуже того Eclipse — более глючного варианта, который постоянно на каждый чих нужно настраивать, а удобства так и не появляется, я не видел.
HID — ни разу не банален.тонкостей в нем вагон и маленькая тележка. Недаром одна спецификация — увесистый том.
Но один раз написав, можно решать основную задачу — двустороннего обмена с ПК очень удобно.
Вот бы еще разобраться с USB HOST на F4, чтобы подключать джойстик к девайсу.
Вот настройка среды и сохранения для раздачи в архиве это доброе дело, выложите в конце статьи, новичкам очень пригодилось бы.
В целом согласен в плане эргономики эмбеддед IDE полная туфта, вилимо производители тратят большую часть ресурсов на компилятор(все таки это не для десктопа писать, где GCC хватает) и отладки, ведь реально много фич появляется: трейс, трейс с энергопотреблением, анализаторы кода и тп, другой вопрос что разбираться с этим черт ногу сломит, но когда какую-нибудь полезную фишку освоишь — куча времени освобождается.
Вы вот знали, что по SDW не только дебажить может но и трейс через SWO? я во недавно узнал и офигел от того насколько это удобно и самое гланвое можно реально поставить программу на прогон хоть на сутки — двое и потом смотреть что из функций отъедает сколько времени, покрытие кода и тд.
В целом согласен в плане эргономики эмбеддед IDE полная туфта, вилимо производители тратят большую часть ресурсов на компилятор(все таки это не для десктопа писать, где GCC хватает) и отладки, ведь реально много фич появляется: трейс, трейс с энергопотреблением, анализаторы кода и тп, другой вопрос что разбираться с этим черт ногу сломит, но когда какую-нибудь полезную фишку освоишь — куча времени освобождается.
Вы вот знали, что по SDW не только дебажить может но и трейс через SWO? я во недавно узнал и офигел от того насколько это удобно и самое гланвое можно реально поставить программу на прогон хоть на сутки — двое и потом смотреть что из функций отъедает сколько времени, покрытие кода и тд.
Производители тратят большую часть времени на разработку самих девайсов и их продажу. :)
IDE — это как маечка в подарок, если она бесплатная. Поэтому они ей занимаются исключительно вынужденно.
Но большинство пользователей МК действительно делают на камне полтора действия и им хватает блокнота.
Я в свое время был удивлен жуткой несовместимостью шилдов к Arduino — надел MotorShield и у тебя ни SPI ни кучи других ножек свободных не осталось, хотя проц еще ничем по сути не занят, но другой шилд уже не надеть. Полная однозадачность. Тупо. мне не понравился такой подход.
Для десктопа писать на порядок сложнее, если что. Я этим занимаюсь много лет, знаю о чем говорю — архитектура ПК гораздо сложнее.
Насчет трейса не очень понял.
IDE — это как маечка в подарок, если она бесплатная. Поэтому они ей занимаются исключительно вынужденно.
Но большинство пользователей МК действительно делают на камне полтора действия и им хватает блокнота.
Я в свое время был удивлен жуткой несовместимостью шилдов к Arduino — надел MotorShield и у тебя ни SPI ни кучи других ножек свободных не осталось, хотя проц еще ничем по сути не занят, но другой шилд уже не надеть. Полная однозадачность. Тупо. мне не понравился такой подход.
Для десктопа писать на порядок сложнее, если что. Я этим занимаюсь много лет, знаю о чем говорю — архитектура ПК гораздо сложнее.
Насчет трейса не очень понял.
Имел ввиду производители IDE, мы же про IAR/Keil говорили.
По поводу средств от производителей МК, тут тоже не все так однозначно:
для многих это вместе с библиотеками ключевое преимущество. Time-to-merket это очень важный параметр и работа R&D зачастую значительно дороже разницы в цене одинаковых МК.
Посмотрите как Atmel форсит свою Atmel studio(на VS кстати), обещают простой инструмент для создания кода, который легко портируется на AVR и ARM туда и обратно.
Cypress для PSoC тоже ввиду особенности платформы дает свою IDE с компилятором от Keil.
Infineon тоже, Renesas, Freescale. TI тоже свою среду запилил, правда без особых плюшек.
За большинство пользователей МК говорить не надо, на МК бывает надо TCP/IP стек перелопатить и с базой данных работать со 128К ОЗУ. Большинство домашних проектов — да это простые управлялки, но это не двигатель рынка.
По поводу шилдов — вообще переход от чистого программирования к смежной области несет кучу сюрпризов, в этом и изюминка: это реальный мир — тут можно и спалить все нахрен :)
Про то что для десктопа писать сложнее — это я думаю от задач зависит, да архитектура сложнее, но такой ограниченности ресурсов там нет и как правило аптайм в много лет не нужен, и часто так глубоко лезть не нужно + куча готовых библиотек, а еще если это не банковский сектор или тп то и сертификация не нужна.
А в РФ разрабатывать бытовуху бесполезно — китай сожрет, в основном и занимаются медициной, счетчиками и тп, куча проверок и сертификации — в автомобилку/авионику загляните вообще черт ногу сломит почитайте про functional safety.
Я думаю вам так кажется, потому что вы со сложными задачами в мире эмбеддед не сталкивались в ПК сталкивались. Вы что же думаете тут разработчики дурака валяют и диодиками мигают?
По поводу трейса почитайте: en.wikipedia.org/wiki/Tracing_(software)
если коротко — то это не беготня по брейкпоинтам а отслеживание каждого ветвления кода и сбор всей статистики. Очень мощный инструмент. Для совсем новичков: например можно ходить назад по инструкциям.
По поводу средств от производителей МК, тут тоже не все так однозначно:
для многих это вместе с библиотеками ключевое преимущество. Time-to-merket это очень важный параметр и работа R&D зачастую значительно дороже разницы в цене одинаковых МК.
Посмотрите как Atmel форсит свою Atmel studio(на VS кстати), обещают простой инструмент для создания кода, который легко портируется на AVR и ARM туда и обратно.
Cypress для PSoC тоже ввиду особенности платформы дает свою IDE с компилятором от Keil.
Infineon тоже, Renesas, Freescale. TI тоже свою среду запилил, правда без особых плюшек.
За большинство пользователей МК говорить не надо, на МК бывает надо TCP/IP стек перелопатить и с базой данных работать со 128К ОЗУ. Большинство домашних проектов — да это простые управлялки, но это не двигатель рынка.
По поводу шилдов — вообще переход от чистого программирования к смежной области несет кучу сюрпризов, в этом и изюминка: это реальный мир — тут можно и спалить все нахрен :)
Про то что для десктопа писать сложнее — это я думаю от задач зависит, да архитектура сложнее, но такой ограниченности ресурсов там нет и как правило аптайм в много лет не нужен, и часто так глубоко лезть не нужно + куча готовых библиотек, а еще если это не банковский сектор или тп то и сертификация не нужна.
А в РФ разрабатывать бытовуху бесполезно — китай сожрет, в основном и занимаются медициной, счетчиками и тп, куча проверок и сертификации — в автомобилку/авионику загляните вообще черт ногу сломит почитайте про functional safety.
Я думаю вам так кажется, потому что вы со сложными задачами в мире эмбеддед не сталкивались в ПК сталкивались. Вы что же думаете тут разработчики дурака валяют и диодиками мигают?
По поводу трейса почитайте: en.wikipedia.org/wiki/Tracing_(software)
если коротко — то это не беготня по брейкпоинтам а отслеживание каждого ветвления кода и сбор всей статистики. Очень мощный инструмент. Для совсем новичков: например можно ходить назад по инструкциям.
Все верно, именно поэтому я считаю Embarcadero RAD Studio и вообще подход RAD гениальной идеей. Она позволяет делать как монструозные тщательно проработанные проекты так и быстро сляпать проектик за 2 минуты. Можно и сочетать оба подхода, главное не набыдлокодить :)
Atmel права, именно поэтому она до сих пор держится — процы то у нее не очень. А вот вокруг них экосистема отличная.
Но Студия у них получилась слабовата — удобна, но функционал не очень — не поддерживает эмуляцию многих МК, потеряли часть вкусных фич из 4й версии. В общем не все гладко. Но как редактор — отлично, Visual Studio отличный выбор. Правда что они там с ней сделали, что она стала работать медленнее чем у MS — хз :)
вот на ПК «как правило» да, но лично мне как раз аптайм важен. Мои девайсы работают на стыке МК и ПК, поэтому мне нужно и софт на ПК чтобы работал надежно и всегда, и на МК то же самое. Готовых либ для ПК море, но они сложнее на многие порядки.
Вот мне нравятся новые мощные МК тем, что можно соединить мощную сложную логику и работу напрямую с реальным миром! это ж мечта детства — чтобы компы не просто картинки и циферки показывали, а могли повлиять на реальный мир и получить обратную связь! А прога на ПК потому что он уже есть и потому что вводить и выводить инфу на нем удобнее в разы.
В РФ разрабатывать как раз полезно. Вот производить можно и в Китае, а разрабатывать и поддерживать нужно именно у нас, с учетом нашей специфики. Можно совместно с китайцами, почему бы нет, так многие корпорации делают.
Нисколько не думаю, что в embedded нет сложных задач, но там они обычно за границами МК — внутри МК все цифровое и понятное, а снаружи — схемотехника, шумы, аналоговый мир. Это в разы сложнее. Программинг МК в разы проще, чем ПК, а вот общий проект со схемой, печатной платой, корпусом, выбором материалов и креплений, софтом и кучей логики — это может быть безумно сложно. Но оно и интересно.
Я лишь хочу, чтобы программинг оставался простым и удобным, потому что самое интересное не воевать со средой разработки, а думать над логикой, управлять реальными девайсами, обрабатывать данные и делать что-то дейтсвительно полезное, вместо того, чтобы кичиться тем, что ты способен собрать прошивку вручную побайтно в HEX редакторе :)
Atmel права, именно поэтому она до сих пор держится — процы то у нее не очень. А вот вокруг них экосистема отличная.
Но Студия у них получилась слабовата — удобна, но функционал не очень — не поддерживает эмуляцию многих МК, потеряли часть вкусных фич из 4й версии. В общем не все гладко. Но как редактор — отлично, Visual Studio отличный выбор. Правда что они там с ней сделали, что она стала работать медленнее чем у MS — хз :)
вот на ПК «как правило» да, но лично мне как раз аптайм важен. Мои девайсы работают на стыке МК и ПК, поэтому мне нужно и софт на ПК чтобы работал надежно и всегда, и на МК то же самое. Готовых либ для ПК море, но они сложнее на многие порядки.
Вот мне нравятся новые мощные МК тем, что можно соединить мощную сложную логику и работу напрямую с реальным миром! это ж мечта детства — чтобы компы не просто картинки и циферки показывали, а могли повлиять на реальный мир и получить обратную связь! А прога на ПК потому что он уже есть и потому что вводить и выводить инфу на нем удобнее в разы.
В РФ разрабатывать как раз полезно. Вот производить можно и в Китае, а разрабатывать и поддерживать нужно именно у нас, с учетом нашей специфики. Можно совместно с китайцами, почему бы нет, так многие корпорации делают.
Нисколько не думаю, что в embedded нет сложных задач, но там они обычно за границами МК — внутри МК все цифровое и понятное, а снаружи — схемотехника, шумы, аналоговый мир. Это в разы сложнее. Программинг МК в разы проще, чем ПК, а вот общий проект со схемой, печатной платой, корпусом, выбором материалов и креплений, софтом и кучей логики — это может быть безумно сложно. Но оно и интересно.
Я лишь хочу, чтобы программинг оставался простым и удобным, потому что самое интересное не воевать со средой разработки, а думать над логикой, управлять реальными девайсами, обрабатывать данные и делать что-то дейтсвительно полезное, вместо того, чтобы кичиться тем, что ты способен собрать прошивку вручную побайтно в HEX редакторе :)
Скажите, а Вы готовы за KEIL заплатить 10k$ или за IAR 3k$ для домашних поделок?
А бывают вообще подобные платы с готовым аналоговым выходом? Есть проект-мечта, где требуется измерять импеданс (комплексное сопротивление).
Хочу посылать синусоидальное напряжение и считывать его же с другого выхода четырёхполюсника.
Хочу посылать синусоидальное напряжение и считывать его же с другого выхода четырёхполюсника.
Интересный проект.
Конечно, например эта. У старших процов серии есть DAC. на F103VE он точно есть.
Вкратце, есть один знакомый кардиохирург, который хочет улучшить один аспект операций — принятие решения о состоянии тканей аорты.
Сейчас решение принимается просто на основании диаметра сосуда. Больше N см — отрезать и менять. Меньше — оставлять. Хотя диаметр это лишь весьма отдалённое последствие коренной проблемы — состава тканей сосуда.
При наличии определённых заболеваний, со временем, стенки аорты накапливают кальций и становятся хрупкими. При резкой нагрузке на сердце эти хрупкие ткани могут лопнуть и их надо заменить.
Так вот, состав тканей можно определить экспериментально в лаборатории — но на это уходят часы. Решение нужно принимать непосредственно в процессе операции.
Я ему предложил измерять сопротивление тканей на разных частотах: просто подключить клеммы в разрез аорты и это гипотетическое устройство за секунды «прозвонит» заданный диапазон частот и покажет процентный состав тканей (жиры, белки, кальций и т.п.).
Сам я программист и с удовольствием занялся бы софтверной частью проекта (там же ещё исследовать всё надо — найти зависимость). Может кто-нибудь помочь с аппаратной реализацией?
На первом этапе (для НИОКР и исследований) нужно лишь получить АЧХ и передать её на комп (потом, в оффлайн-режиме).
Сейчас решение принимается просто на основании диаметра сосуда. Больше N см — отрезать и менять. Меньше — оставлять. Хотя диаметр это лишь весьма отдалённое последствие коренной проблемы — состава тканей сосуда.
При наличии определённых заболеваний, со временем, стенки аорты накапливают кальций и становятся хрупкими. При резкой нагрузке на сердце эти хрупкие ткани могут лопнуть и их надо заменить.
Так вот, состав тканей можно определить экспериментально в лаборатории — но на это уходят часы. Решение нужно принимать непосредственно в процессе операции.
Я ему предложил измерять сопротивление тканей на разных частотах: просто подключить клеммы в разрез аорты и это гипотетическое устройство за секунды «прозвонит» заданный диапазон частот и покажет процентный состав тканей (жиры, белки, кальций и т.п.).
Сам я программист и с удовольствием занялся бы софтверной частью проекта (там же ещё исследовать всё надо — найти зависимость). Может кто-нибудь помочь с аппаратной реализацией?
На первом этапе (для НИОКР и исследований) нужно лишь получить АЧХ и передать её на комп (потом, в оффлайн-режиме).
А что именно требуется по ТТХ?
В обозримом будущем нужно лишь одно-два устройства-прототипа. Даже без корпуса можно.
На устройстве нужны:
— клеммы для подключения контактов, которые уходят в тело пациента.
— кнопка «старт записи» и, возможно, светодиод состояния
— минимально низкое напряжение питания (в идеале от батареек, а не от сети — т.к. с другой стороны живые люди)
По нажатию кнопки устройство:
— посылает синусоидальное напряжение заданной частоты на одну пару клемм
— снимает напряжение с другой пары клемм
— определяет активное и ёмкостное сопротивление на данной частоте (падение амплитуды и задержку по времени) — как можно точнее
— записывает результат в память (на файл на sd-карте или как удобнее в последствии передать на компьютер)
— изменяет частоту и повторяет цикл измерений
Набор частот и все параметры (напряжение, длительность теста) могут быть заложены в прошивке или записываться в память через компьютер.
Выходное напряжение хотелось бы держать минимально допустимое (до 5 В) при сохранении качества измерений. Частоты в районе нескольких килогерц.
Бюджет не так важен.
На устройстве нужны:
— клеммы для подключения контактов, которые уходят в тело пациента.
— кнопка «старт записи» и, возможно, светодиод состояния
— минимально низкое напряжение питания (в идеале от батареек, а не от сети — т.к. с другой стороны живые люди)
По нажатию кнопки устройство:
— посылает синусоидальное напряжение заданной частоты на одну пару клемм
— снимает напряжение с другой пары клемм
— определяет активное и ёмкостное сопротивление на данной частоте (падение амплитуды и задержку по времени) — как можно точнее
— записывает результат в память (на файл на sd-карте или как удобнее в последствии передать на компьютер)
— изменяет частоту и повторяет цикл измерений
Набор частот и все параметры (напряжение, длительность теста) могут быть заложены в прошивке или записываться в память через компьютер.
Выходное напряжение хотелось бы держать минимально допустимое (до 5 В) при сохранении качества измерений. Частоты в районе нескольких килогерц.
Бюджет не так важен.
Рекомендую пролистать вот эту книжку. А с измерителем рекомендовал бы не возиться, а купить какой-нибудь готовый RLC-метер с внешним интерфейсом, потому что одного аналогового выхода тут будет недостаточно и, если вас не особо интересует электронная часть всего этого проекта, так будет значительно проще.
Пятница же завтра, не?
Да не, я просто программист, а моё знакомство с ARM ограничивается ношением Андроида в кармане.
Для меня это всё — волшебная и чёрная магия электричества. Не судите строго.
Для меня это всё — волшебная и чёрная магия электричества. Не судите строго.
Я про название. Всё-равно что «Wordpress vs Zend Framework». И на том и на том делают сайты, только на одном профессионалы, а на другом чаще школьники (причём есть, конечно, случаи, когда заказчик, увидя в интернете популярность WP, желает сайт именно на нём).
Зависит от сайта. Если это блог — WP — то, что нужно.
Абсолютно ничего против WP не имею. Как не имею и против вашего поста. Просто стало интересно, как бы отреагировало сообщество вебразработчиков на заголовок указанный мной.
Я не чужой этому сообществу :) Поэтому могу сказать так — если вы не просто поболтать, а решаете конкретную задачу, то для разных задач есть несколько разных CMS и для блогоновостных сайтов WP подходит хорошо. Главное не пытаться сделать на нем соцсеть, магазин или сложный корпоративный сайт, он для этого не предназначен. Это как пытаться на атмеге сделать телевизор :)
Как раз хотел заняться изучением вопроса подключения stm32 по usb.
Решение на easyelectronics предполагает установку драйверов на компьютер.
Ваше решение использует стандартные драйвера — это огромный плюс.
Не поделитесь исходниками?
Решение на easyelectronics предполагает установку драйверов на компьютер.
Ваше решение использует стандартные драйвера — это огромный плюс.
Не поделитесь исходниками?
Поделюсь. На этой неделе собираюсь написать статью, пока времени нет. Да и код еще грязный, пришлось адаптировать — сходу ни один пример не компилился. Любят эти товарищи изврат коммерческий вроде KEIL и IAR, а я их близко видеть не могу. Ну и там под другую плату. Пришлось адаптировать.
Я по поводу исходников. Где-то уже можно их посмотреть?
Времени никак не было, поэтому могу пока предложить только грязный код, где все вповалку. Если потерпите — выложу более приличный вариант.
Потерплю. Спасибо.
Я настойчивый =).
Так статья давно лежит:
habrahabr.ru/post/208026/
ravenium.ru/tag/stm32/
Там же и исходники.
В принципе, вполне можно пользоваться. Я для себя использую немного в другом виде, но это чисто мои предпочтения.
habrahabr.ru/post/208026/
ravenium.ru/tag/stm32/
Там же и исходники.
В принципе, вполне можно пользоваться. Я для себя использую немного в другом виде, но это чисто мои предпочтения.
Мне stm32f104 приглянулся, разогнал его до 160+Mhz, с флешки читал 12 стерео Wavok с музыкой и мешал легко(тестил). Естественно вывод через DAC так же на стерео микса всех 12 вавок.
Может напишете о своем проекте, если он не коммерческий? Многим интересно было бы.
Была идея сделать комерческим, как релакс звуки для ванной под хромотерапию. Но застопорился на китайских пультах :) Если будет время и вам интересно обязательно напишу.
Интересно. А что с пультами?
Пульт радио разноцветный такой от их коробок со светоэффектами. В принципе у меня есть исходник их прошивки(договорились) написанный на ассемблере и с китайскими ероглифами в коментариях. Выглядит эпично. Но разобраться уже не было времени и так проект потихоньку свернулся. Могу заного собрать установку если найду исходники и описать это на хабре. В принципе там интересненько, потому что реализован недо свой звуковой движок, простой очень но любопытный)
крутяк
Недавно тоже приобрел такую платку, должна приехать через пару недель.
BTW, поделитесь пожалуйста — какие есть бесплатные IDE для MacOS/Linux для разработки под stm32?
BTW, поделитесь пожалуйста — какие есть бесплатные IDE для MacOS/Linux для разработки под stm32?
Под MacOS и Linux всегда было все плохо со средами разработки. NetBeans, Eclipse — со всеми их недостатками. Можно использовать CodeBlocks — она есть под Linux. Я в ней под AVR пишу, с отладкой не возился, но настроить можно. У меня лежит CodeBlocks под Windows настроенная для AVR и STM32.
Сам пользуюсь для STM32 в основном EmBlocks и CoIDE.
Сам пользуюсь для STM32 в основном EmBlocks и CoIDE.
Все, кому не лень, ругают Eclipse. Хотелось бы хоть раз услышать, что именно в нём настолько плохо, что вы выбрали CodeBlocks.
Тормоза, неудобные настройки, огромный размер, необходимость настраивать КАЖДЫЙ новый проект по новой — десятки действий и если хоть одно пропустишь — не компилится. CodeBlocks позволяет сделать шаблон проекта и настроить скрипт визарда, после этого проект будет создаваться правильно настроенным. Нужно только выбрать из списка проц и дебаггер. Emblocks еще и заточен под Embedded разрабокту.
Я привык к нормальным IDE — в Visual Stduio проект создается готовым для наполнения моим кодом — все настроено и компилируется после работы визарда. В Delphi все то же самое. Я считаю это правильным. Тратить время на повторяющуюся работу по настройке проекта каждый раз, когда я пробую Blink или еще какой мелкий тест — это глупо. Тупую работу должен делать компьютер, он для того и создан.
Я привык к нормальным IDE — в Visual Stduio проект создается готовым для наполнения моим кодом — все настроено и компилируется после работы визарда. В Delphi все то же самое. Я считаю это правильным. Тратить время на повторяющуюся работу по настройке проекта каждый раз, когда я пробую Blink или еще какой мелкий тест — это глупо. Тупую работу должен делать компьютер, он для того и создан.
В основном это скорость работы, если есть хороший компьютер с быстрой памятью и IDE удобно настроена производителем/другом/вами то никаких проблем нет: куча плагинов и отличный редактор кода.
Даже на быстром компе с SSD она умудряется долго запускаться и время от времени глючить. А на ноуте со скромным двухъядерным Celeron 1.2 и 4ГБ памяти она просто тормоз. Судя по минусу за комментарий что-то людям не понравилось — либо что я считаю их любимый эклипс тормозом либо что среда должна быть удобной :)
Аскеза — это для монахов, я же предпочитаю удобные средства разработки. Молоток должен хорошо лежать в руке и не слетать с рукоятки. Ножовка пилить ровно и быстро, а не рвать материал, а IDE не должна заставлять делать лишние действия там, где они повторяются и стандартны. Все должно быть под рукой и удобно разложено. если что-то делается часто, нужно иметь возможность настроить Hotkey и так далее.
Аскеза — это для монахов, я же предпочитаю удобные средства разработки. Молоток должен хорошо лежать в руке и не слетать с рукоятки. Ножовка пилить ровно и быстро, а не рвать материал, а IDE не должна заставлять делать лишние действия там, где они повторяются и стандартны. Все должно быть под рукой и удобно разложено. если что-то делается часто, нужно иметь возможность настроить Hotkey и так далее.
Из за центровки числа 10 на монете и акценте штриховкой на внутреннем пространстве ноля, монета выглядит как 0 рублей. Сорри за оффтоп.
Также есть вшитый бутлоадер, который невозможно стереть
Вот это супер, только интересно как реализовано: отдельной микрухой (это было б хорошо, если б еще она вообще неперезаписываемая была) или на той же перепрошиваемой, просто как-то заблокировано (тогда фуфло такая защита бутлоадера).
Это аппаратный бутлоадер в самом чипе. управляется комбинацией пинов BOOT0 BOOT1: Для входа во встроенный загрузчик, надо чтобы во время и после аппаратного сброса микроконтроллера на выводе BOOT0 был высокий уровень, а на выводе BOOT1 – низкий.
Я бы не назвал это аппаратным, все-таки. Это такой же STMовский код, просто лежит в отдельной области памяти и зашит туда при производстве.
Аппаратный это как в старых самсунговских, кажется, процессорах — отдельная микруха, копирующая содержимое с флешки в оперативную память, чтобы потом процессор мог оттуда загрузиться)
Аппаратный это как в старых самсунговских, кажется, процессорах — отдельная микруха, копирующая содержимое с флешки в оперативную память, чтобы потом процессор мог оттуда загрузиться)
Ок, пусть так, разница между ним и реализацией в ROM невелика — ни то ни другое не поддается изменению и то и другое не занимает пользовательский флэш и всегда встроено и в вашем распоряжении.
Главное, что не занимает места на плате в виде отдельной микрухи, как предположили выше…
Кстати, есть STMки с радиоинтерфейсами внутри, их бутлодер не может по этому радио грузиться?
Upd:
Посмотрел, могут. Надо бы найти отладочную на них, похоже, прикольная штука.
Кстати, есть STMки с радиоинтерфейсами внутри, их бутлодер не может по этому радио грузиться?
Upd:
Посмотрел, могут. Надо бы найти отладочную на них, похоже, прикольная штука.
Ага, не успел ответить ) по идее офигенная штука. Проблема в том, что там более ущербные МК обычно
Ну так, средненький, не то чтоб ущербный. Для многих целей хватит.
Но у меня лично пропадает желание с ним экспериментировать после прочтения их апноутов по проектированию печатной платы под ВЧ, не умею я это делать, сталкиваться пока не приходилось, и вот так вот начинать это копать и тестить желания пока нет, тем более, что там не помешает оборудование специальное, чтобы тестить то, что получилось, а ВЧ оборудования у меня тоже, понятное дело, нет.
Но у меня лично пропадает желание с ним экспериментировать после прочтения их апноутов по проектированию печатной платы под ВЧ, не умею я это делать, сталкиваться пока не приходилось, и вот так вот начинать это копать и тестить желания пока нет, тем более, что там не помешает оборудование специальное, чтобы тестить то, что получилось, а ВЧ оборудования у меня тоже, понятное дело, нет.
о, ВЧ и дискретная схемотехния для меня — дикий ад. Я мало что в этом понимаю. Для меня самое интересное — это соединить/спаять все, а потом программить. Рассчитывать какой нужен резюк, конденсатор, форма и длина дорожки, какой поставить разъем, чтобы согласовать сопротивления — это абсолютно для меня неинтересно.
Главное не отдельная микруха, а неперезаписываемость, даже с костылями :)
Я от электронщиков, сколько историй слышал о повреждении бутлоадеров телефонов, что просто стремно, и перепрошить или нечем или невозможно… Если бы бутлоадер был непрошиваемой микрухой (однократнопрошиваемая — тоже прошиваемая), то таких инцидентов не было бы. В крайнем случае сгорела бы микруха и все. Но в таких ситуациях сгорела бы любая…
Я от электронщиков, сколько историй слышал о повреждении бутлоадеров телефонов, что просто стремно, и перепрошить или нечем или невозможно… Если бы бутлоадер был непрошиваемой микрухой (однократнопрошиваемая — тоже прошиваемая), то таких инцидентов не было бы. В крайнем случае сгорела бы микруха и все. Но в таких ситуациях сгорела бы любая…
Это отдельная область памяти на кристалле контроллера. И чем же она «фуфло»?
Это мое личное мнение на счет «фуфла». Расшифрую: если возможно убить бутлоадер программно, то защита — «фуфло», т.е. в ней нет смысла.
И как вы его собрались убивать программно?
Нет, но в жизнь сложная штука :) Порой такие «приколы» случаются, что… Короче говоря лишняя предосторожность не помешает.
Чушь. если в МК нет бага, то вы никак ее не сотрете. Если баг есть — то нафиг этот МК. Я не знаю случаев, чтобы у кого-то получалось стереть бутлоадер STM32. Сдуру, конечно, можно и хрен в двух местах открытым переломом сломать, но изврат я не рассматриваю. Вещей которые нельзя сломать принципиально на свете не существует.
Я в роли экспериментатора все могу :)
Например стереть биос тоже невозможно по ошибке, но… Для перезаписи отправляется несколько комманд в некотором порядке, после чего запись в биос разрешается и твори что угодно. Можно предположить, что появление такой последовательности случайно невозможно, но теоритически — возможно. И запись хоть одного неправильного бита будет достаточно — это выведет его из строя.
Например стереть биос тоже невозможно по ошибке, но… Для перезаписи отправляется несколько комманд в некотором порядке, после чего запись в биос разрешается и твори что угодно. Можно предположить, что появление такой последовательности случайно невозможно, но теоритически — возможно. И запись хоть одного неправильного бита будет достаточно — это выведет его из строя.
Если б я знал как оно получается :)
В статье ничего не сказано об энергоэффективности сравниваемых контроллеров.
Например, atmega328p выполнен по технологии picoPower и питается от 1.8в, потребляя 18мА.
Например, atmega328p выполнен по технологии picoPower и питается от 1.8в, потребляя 18мА.
Энергоэффективность- понятие очень абстрактное. У STM32 есть несколько режимов работы, потребление зависит от того внешний или внутренний источник тактирования, какая периферия включена. Все это есть в даташите. Статья рассчитана на начинающих. Если вас этот вопрос серьезно занимает, все данные есть в даташитах. Там целый раздел посвящен этому вопросу.
Стандартный atmega328p работает от 5в. На 3.3в он работает только на 8МГц
Стандартный atmega328p работает от 5в. На 3.3в он работает только на 8МГц
И у STM32, и у Atmel328p есть несколько режимов работы.
Интересно сравнение энергопотребления на схожих режимах при равных условиях, например, внутренний источник тактирования и отсутствие периферии.
Интересно сравнение энергопотребления на схожих режимах при равных условиях, например, внутренний источник тактирования и отсутствие периферии.
у STM32 есть серия STM32L1, которая точно экономичнее и быстрее чем AVR, поэтому сравнивать особо нечего. AVR я бы использовал там, где лень делать свое устройство, нужно по-быстрому что-то сваять. Тогда можно купить сверхдешевую Arduino Pro Mini и воткнуть ее, набросав программу на С.
А если мне нужен нормальный функционал, гибкость и удобство — STM32 без раздумий. А дальше в зависимости от потребностей конкретная серия и проц. STM32 мне напоминает ПК — дофига возможностей, очень гибкий, высокая производительность, хорошая совместимость.
Кстати, без периферии МК нафиг не нужен — в ней вся суть микроконтроллера. Поэтому абстрактные миллиамперы в вакууме неинтересны. А в конкретной задаче всегда можно посмотреть в таблице значения. Они расписаны для разных температур, даны типичные и максимальные значения. Да и внутренний источник тактирования не обладает нужной мне точностью, поэтому неинтересен.
А если мне нужен нормальный функционал, гибкость и удобство — STM32 без раздумий. А дальше в зависимости от потребностей конкретная серия и проц. STM32 мне напоминает ПК — дофига возможностей, очень гибкий, высокая производительность, хорошая совместимость.
Кстати, без периферии МК нафиг не нужен — в ней вся суть микроконтроллера. Поэтому абстрактные миллиамперы в вакууме неинтересны. А в конкретной задаче всегда можно посмотреть в таблице значения. Они расписаны для разных температур, даны типичные и максимальные значения. Да и внутренний источник тактирования не обладает нужной мне точностью, поэтому неинтересен.
Sign up to leave a comment.
STM32 vs Arduino