artymen

Да, я посмотрел community edition, выглядит впечатляюще, но мне надо для коммерческого использования и бесплатную :(

Вот его я и ковыряю сейчас, но в нем нету диаграмм компонентов и пакетов. И нетрудно догадаться почему: замечательная диаграмма классов заменит их все !

Хм. Я когда-то давно прочитал о ДРАКОНе, посмеялся. Не думал, что всерьез его кто-то применяет. Почитал каменты, заставили задуматься. Но все же есть сомнения, что вряд ли такой подход сгодится для сложного проекта (сложность не в плане алгоритмов, а в плане конфигурации, линковки и т.п.), да еще и в командной работе. Но прямо сейчас я все равно не буду совершать столь коллосальную революцию сознания :) Я считаю, что такого же эффекта, но с более гибким применением, можно добиться путем рисования диаграмм и последующего написания кода, при этом надо самому следить за соответствием диаграмм и кода при изменениях в течение жизни проекта. Упс, я кажется в корне ошибался насчет UML. На википедии сказано, что Теперь понятно, почему я мучаюсь :smile3046:

Хотелось бы узнать, какими инструментами эмбеддеры пользуются при проектировании встраиваемого программного обеспечения ? Необходимо описывать программу на базе RTOS: взаимодействия между потоками, функциональный состав модулей, алгоритмы, состояния и т.п. Полученные диаграммы должны экспортироваться в картинки (без ватермарков и прочей фигни). Редактор должен быть бесплатным. И желательно чтобы все диаграммы в одном проекте/workspace можно было объединять. Я перебрал кучу UML-редакторов, но так и не нашел адектватного инструмента: либо неинтуитивные, либо дико неудобные, либо помешанные на ООП. Особенно последним страдают, несмотря на то что UML сам по себе универсальный, как следует из названия, но в мире программирования почему-то принято, что все занимаются либо веб-программингом, либо в Qt/Visual Studio формочки рисуют для офисных приложений. Причем игнорировать ненужную функциональность сложно. Редактор все время пихает под руку эти дурацкие классы... порождает автоматически кучу ненужных артефактов... в каждом создаваемом мною объекте пытается увидеть класс со всякими свойствами, методами, интерфейсами и прочей ненужной мне лабудой... Реально ничего больше не остается, как пользоваться либо пэйнтом, либо громоздкими рисовалками общего применения (MS Visio и т.п.). P.S.: Не ругайтесь, если не туда тему запостил, но я все разделы форума перерыл в поисках подходящего.

Ну как то извратно мне кажется. Если уж на то пошло, то наверное правильнее использовать систему hz или bzr. В-общем, пока что наилучшее решение для меня, это работать с msysgit и EGit вместе. :)

Сервер однозначно локальный. Об онлайновых даже и речи не может идти. Что касается метода доступа (по git-протоколу, webdav, gitweb и т.п.), то уже все равно какой. Лишь бы клиент виндовой был нормальный.

Ищу хоть-какой нибудь git-клиент под windows, сделанный НЕ на базе msysgit. (Пока знаю только EGit в эклипсе. Но лезть в эклипс, заходить в какой то конкретный workspace или создавать workspace чисто для работы с репозиториями, это изврат, имхо.) Дело в том, что хваленый и популярный msysgit имеет чудной баг, который разработчики не могут выловить и судя по развернувшемуся бурному обсуждению в комментах, не хотят вылавливать, несмотря на убивания пользователей об стенку. Я просто один из этих счастливчиков, страдающих этим багом. Я перепробовал всевозможные git-клиенты, и все они в конечном счете являются всего-лишь фронтендом для msysgit (даже если тщательно скрывают эту "деталь" в описании/документации). Может кто нашел данную редкость на просторах инета ?

Попробовал, работает. Только это конечно не совсем то, что хотелось, но хотя бы так. Я то хотел перенаправление на уровне ввода/вывода стандартной библиотеки. А это просто отдельная библиотека отладочных функций. Я, кстати совсем и забыл про эту альтернативу j-link'овскому gdb серверу. Правда полдня бился с этим openocd. Нестабильно он работает с jlink'ом. Впрочем, это отдельная тема.

Спасибо, попробую.

В платных средствах разработки (IAR, Keil) есть такая замечательная вещь - semihosting (перенаправление stdio target-системы на host-систему через jtag/swd). Хочу такое же в GNU-шной связке заиметь :) Насколько я понимаю, нужно переопределить библиотечные функции stdio так, чтобы они читали/писали в регистры DCC, а gdb должен все время поллить эти регистры каким-то образом и вводить/выводить на виртуальную консоль. В инете ничего не нашел. Возможно ли это вообще ?

Все, разобрался ! Как всегда, все банально - проц не сбрасывался в начале отладки. :krapula: Опции "Reset and Delay" и "Halt", оказывается, не работают, собаки. Это баг/фича в "C/C++ GDB Hardware Debugging" (version 7.0.0.201009241320) feature в Eclipse CDT. Нужно вручную прописывать команду "monitor reset 0", что собствено и делается во всех gdbinit-скриптах. А я сдуру решил, что это избыточно (ведь в среде есть эти опции), что и привело к потере времени :cranky: Причем обидно, что я все время смотрел окно сообщений gdb сервера и не замечал, что привычное сообщение типа "Resetting target" нигде не мелькает.

Столкнулся с такой неожиданной проблемой: при отладке программы с freertos на LPC1768 (cortex m3) под gdb (yagarto toolchain) через j-link (gdb server) отладчик останавливается безо всякой на то причины на инструкции SVC 0 в коде фриртоса (в функции vPortStartFirstTask), как будто breakpoint сработал. Делаю resume, но он зацикливается на этой инструкции. Отлаживаю во флеше. В конфигурации отладки в Eclipse прописаны команды инициализации: monitor endian little monitor flash device = LPC1768 monitor flash download = 1 monitor flash breakpoints = 1 monitor speed 1000 monitor reg r13 = (0x00000000) monitor reg pc = (0x00000004) Ну и разумеется опции Reset and Delay и Halt включены. Set breakpoint at: main и Resume. Запускается нормально, на main останавливается, продолжаю, и вскоре останавливается на vPortStartFirstTask. Причем я забил на свой код, попробовал отладить стандартный пример CORTEX_LPC1768_GCC_RedSuite из FreeRTOS 6.1 (но не в redsuite, а yagarto опять-таки). То же самое. Однако всякие IARовские примеры отлаживаются нормально. Кто сталкивался ? В чем тут может быть дело ?

Спасибо за ответы. Push button controller это как раз в точности то, что я себе и представлял. Но стоимость сего примитивного чипа, конечно, дикая. Я бы больше 10 рублей не дал. А на транзисторах походу самое лучшее и адекватное решение. Я не силен в аналоговой технике и работу транзисторов слабо представляю, но идею я понял. Тут мне подсказали еще идею с триггером с защелкой (D-триггер или какой-то там, уже не помню, какой) :)

Подозреваю, что есть микросхемы коммутации питания от клавиатурной кнопки, либо есть стабилизаторы с такой функциональностью. Т.е. микросхема должна потреблять считанные микроамперы, и по замыканию управляющего входа на землю или на питание (с определенной мин. длительностью) должна выдавать питающее напряжение на весь девайс, после чего, конечно же, управляющий вход размыкается, но питание не пропадает. Если такие есть, подскажите как это вообще называется, какие ключевые слова гуглить и т.п. ? Просто делается обычно так: простенький малопотребляющий микроконтроллер ставится, который все время спит, считывает кнопку и включает стабилизатор, который подает питание на главный микроконтроллер и т.д. А на главном микроконтроллере сделать так нельзя, потому что даже в самом глубоком сне он потребляет слишком много. Но это мне кажется извращенным велосипедом.

Спасибо. Но меня уже убедили в извратности такого решения :) Да и к тому же выяснилось, что в devprom можно и "вручную" с репозиторием связывать артефакты, не так уж и страшно.

Т.е. я могу запустить svn-сервер, создать на нем svn-репозиторий, в devprom'е подключить этот репозиторий по url, потом отдельно создать git-репозиторий, в нем настроить "синхронизацию" с svn-репозиторием, а потом работать себе спокойно с git-репозиторием, и в devprom'e автоматом будут видны все изменения ?

Нашел просто офигенную систему управления проектами DEVPROM, во всех отношениях она замечательна, да вот интегрируется она только с морально устаревшим SVN. Прямо влюбился в нее, а там такой досадный недостаток. Можно ли как-нибудь прикрутить Git или Mercurial ? Я даже согласен на извратное решение типа "конвертера" svn-запросов (через webdav или что там) в git-репозиторий.

Омапы уже смотрели в плане DSP. По каким-то причинам отказались. Как я уже говорил в начале, ARM7 достаточно, но это для простой трубки, а мы планируем расширять функционал. Рассматриваю только варианты выше. Энергопотребление, конечно, важный для нас параметр, но все же не первый. Смотрю в сторону LPC2900. Но хотелось бы все-таки кортекс аналогичный, для него HAL стандартизован. Я с CMSIS поработал, очень понравилось. :)

AlexandrY, хорошо... А что значит "В коммуникационной части ARM9 в чистую проиграли Cortex-M4." ? Вы имеете в виду набор периферии или просто область применения ? Если по потреблению он не хуже, то конечно же я с радостью выберу его, раз он гибок в отладке, да и лишняя мощность позволит легче реализовать некоторые вещи (например, можно взять навороченную GUI-либу и достаточно быстро построить интерфейс, чем самому по кирпичикам писать, что уже и сделано). Ну я считаю, что портирование это довольно трудоемкая работа, уж тем более когда речь идет о TETRA. EDIT: Оказалось, кортекс-м4 не мощнее :) В-общем, если ести гигагерцовые кортексы не хуже по потреблению, то с радостью. Просто я не совсем ориентируюсь в процессорах, и для меня излишняя мощность означает соответствующее потребление. Но походу все несколько сложнее :)

Спасибо за ответы. Разумеется, будет DSP помимо АРМа. А на АРМе будет крутиться все: и верхние уровни стека протокола, и UI и т.д. Про андроид, линукс, OpenGL и 1-ГГцовый кортекс, я считаю, перегнули :) Это относительно простая радиостанция для критических применений, а не ширпотребный навороченный коммуникатор с рюшечками. RTOS однозначно. Собственно по теме. Я спрашивал конкретно про АРМ9, и знаю, что АРМы в целом неубиваемы :) Значит, берем АРМ9 и особо не беспокоимся :)

Выбираю микроконтроллер для разработки радиостанции TETRA. Однако, она будет не столь простой, чтобы хватило с запасом ARM7 или Cortex-M3. Я остановил свой выбор на ARM9E, да и один опытный специалист мне его посоветовал именно в данном применении. Смущает только то, что коллега считает, что ARM9 скоро вымрут на своей нише или станут неактуальными. Хотелось бы узнать мнения. Если опасения оправданы, то какие альтернативные решения есть, например, аналоги из кортексов ? Или, возможно, не о чем беспокоиться ?

Все, победил ! :yeah: Всем спасибо. Теперь буду знать об этих граблях :) Не, все нормально, компилятор то один и тот же. Это я, просто сначала сделав правильные аттрибуты (aligned(2), packed), неверно кое-что истолковал и убрал packed, потом понял, что я неверно истолковал и вернул обратно. Теперь все работает, как надо :)

Ну елки палки ! Выровнял я свои данные. Теперь Qt'шный gcc и Yagarto'вский gcc по-разному стали размещать поля в структурах, объявленных с аттрибутом aligned(2) (до этого packed были). :angry2: Дело в том, что у меня кроссплатформенный код. На Qt все работает нормально, как и было до выравнивания. Другого быть впрчоем и не может, потому что другая программа на том же самом Qt и запихала данные в структуру, и прочитались они соответсвенно аналогичным образом. А вот теперь в АРМе они читаются по-другому. UPDATE: Выяснил. Опять дата аборт. Теперь он произошел при word'овом доступе. Ясно теперь, откуда взялись лишние 2 байта в структуре... Вобщем, еще немножко переделаю, раз уж такие интересные подробности выравнивания структуры и эелемнтов внутри нее выяснились :)

Хм, классно. Выходит, IAR рулит :) И все же во мне теплится надежда, что gcc не отстает в этом вопросе и где-то в его глубинах все же заложена подобная возможность, надо только 700 страниц мануала перелопатить и всего-то

Ну тогда я не понимаю, что вы имеете в виду под "побайтовым" доступом.