legotron

После подобных телодвижений, как правило, что-то сгорает. Таким образом отсеиваем неверный вариант методом проб и ошибок. логика! :) Может начать с того что Vcc с GND поменять? (пусть никто не примет за совет! на всякий случай)

А мне кажется, что программа должна быть написана таким образом, чтобы оптимизация сильно не влияла на ее работу. Временные интервалы, периоды таймера, частота кварца должны выбираться с запасом, чтобы +-100 тактов роли не играли. Чтобы не тратить время на чтения дизасемблера. Мое резюме такое: ассемблерных вставок должно быть не более 10-20% кода, если получается иначе, то можно подумать о том, чтобы писать на чистом ассемблере, если уж у вас устройство критично по потреблению, что вы не можете взвинтить тактовую. Всё гениальное просто :)

не претендую на грамотность :) А может воспользоваться POST-COMMIT HOOK. Написать скрипт, который после коммита проекта с либой создаст tag, содержащий нужные файлы, который всегда будет связан svn:externals с проектом, в котром используется эта либа. Таким образом вы правите тестовый проект, производите фиксацию, нужные файлы попадают в tag, который связан svn:externals с другим проектом. P.S. Не бейте сильно, если чушь написал. я из благих намерений

А почему бы не использовать Matlab? Там есть и КИХ и БИХ. Плюс есть ФЧХ и картинка с полюсами! Плюс всё можно качественно промоделировать.

Неужели мне какую-то каку от мелкософта нужно ставить :crying:

зачем вам именно ассемблер? если вы никогда не работали ни с ассемблером ни с языком С, однозначно советую вам начать писать на С. "надо" - это универское задание? Неправда, у меня дома валяется небольшая книжка по написанию программ на ассемблере для С167 (в первом приближении одно и тоже что XC167) Это с радостью, мы добрые :) см. mail На русском могу посоветовать только ту книжечку которая лежит у меня дома (позже уточню название). Также классические книги по ассемблеру (не берусь советовать) и С (K & R). А так читайте даташит по XC167. Могу прислать, но вряд ли вы сним разберетесь без посторонней помощи. Советую посмотреть примеры в кейле. Вот вам несколько советов: 1. Если это ваш первый опыт с микроконтроллерами - забросьте подальше XC167 и осваивайте например AVR. 2. Не начинайте изучение с ассемблера, тем более такого как в XC167. Начните с С, и в 99% случаев вам его будет предостаточно. На ассемблере пишут либо те, кто писал программы до появления приличных компиляторов, либо те, кому он реально нужен для достижения соответствующих целей. Целиком программы на ассемблере пишут на сегодняшний день единицы. В основном используется inline-asm, либо пару asm-файлов на десятки сишных в рамках одного проекта. Если же конечно, вам необходимо работать именно с XC167 и именно на ассемблере в силу каких-то обстоятельств, то постарайтесь начинать с простых программок (ни в коем случае не начинайте смотреть примеры сгенерированные С-компилятором, а то еще не равён час и принципы работы компилятора выучите, его оптимизацию, правда уйдет на это лет 5 минимум, ну да ладно :))... Удачи вам! Очень дельный совет! Сам неоднократно там спрашивал. Очень отзывчивые люди отвечали, причем грамотные и к тому же быстро. Этот форум у меня в свое время на 2 месте после электроникса шел. Там можно было оперативно получить ответы на вопросы по инфиненону и кейле в течении дня, в то время как на электрониксе на это уходили недели (пока спецы по инфинеону появяться на форуме). Был случай человек даже просил обязательно сообщить ему о моих результатах, и говорил дальше будет помогать решать проблему, тратил уйму времени на мои косяки.

от создателей µC/OS-II: µC/GUI добавлено: Ой, каюсь, забыл что в теме GNU/OpenSource нахожусь. Библиотека, предложенная выше, сугубо платная! причем дорогая :)

working copy файлов либов будут в папке с проектом (как сами пожелаете), а репозиторий, в котором они находятся может быть отдельный. Может быть также и общий репозиторий, это не столь важно, главное чтобы вам было удобно.

Я завёл отдельный SVN-репозиторий для собственных библиотечных файлов. При этом желательно правильно организовать его дерево каталогов, например по Target-ам (AVR, ARM, x86). Далее просто время от времени добавляете в репозиторий свои библиотечные файлы и не забываете писать подробный commit. Со временем у вас образуется база либов, которую вы сможете подключать к версионированным проектам (для SVN - externals) Вообщем идея примерно такая. P.S. Не обязательно использовать именно SVN, есть и другие системы контроля версий, выбираете какая вам больше нравиться.

Какая версия Windows? Случаем не Vista? А то у меня были похожие проблемы непонятного происхождения с ActiveHDL на Vista.

Самый простой способ в данном случае - взять Makefile, сгенерированный студией и подключить его как внешний (одну галочку поставить), а потом в нем потихонечку что-то менять, добавить зависимость для плюсовых файлов с плюсовым компилятором будет несложно. Также посмотрите красивые примеры Makefile-ов, например для scmRTOS (gcc-avr.mak можно смело брать за основу) P.S. И еще, будьте аккуратнее со смешанными проектами (одновременно С и С++), не забывайте про extern "C" {}

Я вел речь о КА применительно к построениям меню. Отошел только с примером коммуникационного протокола (виноват, неправ). А так с вами целиком и полностью согласен, что проектирование Конечных Автоматов - сложное занятие и тут IAR VS можно считать игрушкой. Но для меню считаю очень и очень пригодным. К тому же есть еще 1 большой плюс, сразу же после того как у вас меню заработало, у вас есть отличнейшая его документация в виде диаграммы для заказчиков, юзеров, и т.д. и т.п. Не нужно тратить время на конвертацию типа "Си-код -> схема".... Конечно профи пишут программы от обратного "схема -> СИ-код"... но это уже тема сооо-о-всем другого топика :)

В данном топике речь идёт о меню. Можно пример ваших усложнений касательно построений меню? Я себе мало представляю меню с размытой логикой, но подозреваю, что если такое и можно придумать, вряд ли возможно будет этим пользоваться с точки зрения эргономики. Хорошее меню - простое меню. Тому пример старые модели телефонов Nokia. добавлено: пару нажатий кнопок и ты уже рубаешь в змейку ;) Код генерируемый IAR VS - нечитабелен, ибо там всё завязано на 1 таблице, которую без бубна не расшифруешь :rolleyes: , но всё остальное по-моему вполне вразумительно (в сравнении с другими программами с автогенерацией кода) К макросам лично у меня сложилось весьма предвзятое отношение, я считаю что они сильно усложняют чтение программ сторонними людьми, а также могут содержать ошибки, которые трудно отыскать. Вы очень хорошее резюме сделали, на самом деле очень часто хочется писать "как хочу", а знающие люди говорят - не надо так писать, и только через какое-то время понимаешь, что они были правы и главное - почему. Поэтому я лично часто говорю себе - "не буду так писать (как хочеться).... почему?(сам себе).... не знаю, но всё равно не буду, потом пойму" На мой взгляд это хороший способ для простых меню. (то что я подразумевал под вариантом 2) Чуть возрастёт логика и способность чтения экпоненциально усложняется. Нормальный подход для простых меню. А усложнить например можно добавив память в дочерние состояния, а если их еще несколько...

Внесу свои 5 копеек. Я решал задачу построения и обработки меню следующими способами: 1 способ - аля AVR Butterfly Качаете исходники и по 5 раз перечитываете их в отношении меню (я именно так и делал, когда-то давно, сразу понять принцип было тяжело :) ) но у меня был сам батерфлай, поэтому мне было проще. Какие плюсы на мой взгляд: 1. Красивая организация кода 2. Достаточно просто прослеживается логика 3. Всё написано на чистом С 2 способ - жесткий самопал :) Подходит для совсем маленьких меню, ~10-20 пунктов. Просто пишите конструкции switch, if, else Для простых меню, которые не подразумевается расширять - то что надо, писать быстро, код получается читабельным (повторюсь, только для маленьких меню!) 3 способ - мой любимый (да простят меня гуру) - Visual State Machine IAR Visual State Quantum Leaps (сложнее и мощнее) Начну с плюсов на примере IAR VS: Если не брать в расчет сколько времени нужно потратить чтобы ваш конечный автомат заработал нормально, ощущение когда всё правильно работает с Deep-state и Shallow-state логикой - просто поросячий восторг!!! Рисуете графическую UML-диаграмму своего меню (оооо-да всё перед глазами, сразу видно , несомненный плюс) Симулируете свою диаграмму в реальном времени!!! просто жмёте кнопки событий, видите как работают таймеры таймаутов и прочие-прочие сладости.. Отлаживаете свою диаграмму в железе в IAR-e, я так отладил коммуникационный протокол по RS-485 прямо под JTAG. Тоже детский восторг вызывает, скажу честно. Всё что вам нужно - это добавить несколько авто-сгенерированных файлов в свою программу и немного во всё это воткнуться... Также поддерживает C++.. там тоже есть прелести.. Есть очереди, ну и многое другое, копаться можно долго. Минусы я вижу в том что это слишком долго настраивается и изучается, по сравнению со способом 2 день и ночь. Также возможны трудно уловимые баги самой программы, на которые можно наткнуться.. Вообщем сейчас уже этой штукой не пользуюсь для меню, но время потраченное на ее освоение не жаль, если бы мне приходилось очень часто писать конечные автоматы, я бы по сей день бы пользовался, а так многое забывается и приходиться тратить слишком много времени на то, чтобы вспомнить. P.S. Вообщем, мои 5 копеек :) Добавлено: Не подумайте что IAR VS можно использовать только с IAR! просто в ИАРе есть дебаггер для визуал стэйт. А так подходит для любых ANSI C компиляторов.

Без этого никак, новые препараты нужно на ком-то тестировать. Предлагаете тестировать на людях??

А можно ссылочку на чудо-скрипты? :)

что-то не выходит :crying: старый svnadmin (svn 1.4) не хочет разворачивать дамп сделанный новым (svn 1.6)... (для опытов переименовал svnadmin добавив версию) svnadmin_1_6 dump e:/_SVN_/REP_AVR_adc_test > e:/git_svn_test/dump/rep_adc_dump.dump svnadmin_1_4 load e:/git_svn_test/rep/rep_adc_test_1_4 < e:/git_svn_test/dump/rep_adc_dump.dump Ошибка при load: svnadmin: Expected FS format '2'; found format '3' я что-то не так делаю?

2All: Уважаемые, не могли бы вы объяснить, в чем суть различий?? Почему на ATxmega работать не будет?? Очень интересно понять смысл вопроса, не выкидывать же многотысячные строки дизасемблера в форум для принятия решения, будет работать на ATxmega или нет..

Выделяем папки: MODULES := ../src \ ../inc \ ../src/scmRTOS/Common \ ../src/scmRTOS/AVR \ Пример зависимости: *.o от *.с $(OBJDIR)/%.o : %.c echo ==== Compiling {:content:}lt;; \ $(CC) -c $(CFLAGS) $(addprefix -I,$(INCDIRS)) \ -Wa,-ahlmsd=$(LSTDIR)/$(notdir $(<:.c=.lst)) {:content:}lt; -o $@ Этого вполне хватает... вообще посмотрите как написаны чужие мэйк-файлы(например scmRTOS) и погуглите "makefile" или посмотрите по форуму.. существует весьма доходчивая литература в т.ч. на русском Отредактировал: Только сейчас понял что вы хотели, к сожалению, не знаю можно ли это делать или нет, но думаю что смысла в этом нет, ибо исходники лучше хранить с мэйк-файлом вместе и никуда их не терять и не разбрасывать :)

Доброго времени суток! Появилось желание перенести старые SVN-проекты под Git. Windows Subversion 1.5.4 git-svn version 1.6.3.2.1299.gee46c (svn 1.4.6) В связи с этим возникла следующая проблема: Пытаюсь выполнить... $ git svn clone file:///E:/_SVN_/REP_Test/trunk В ответ... Couldn't open a repository: Unable to open an ra_local session to URL: Unable to open repository 'file:///E:/_SVN_/REP_Test/trunk' : Expected FS format '2'; found format '3' at C:\Program Files\Git/libexec/git-core/git-svn line 1544 Предполагаю несовместимость версий... :laughing: что посоветуете?

:bb-offtopic: Часто встречаю подобные высказывания на форуме, а у меня обратная картина. Иногда нужно использовать ассемблер.. Ну никак не могу с ним научиться дружить :( Особенно инлайн-ассемблер в GCC (это вообще еще та китайская грамота)

Возможно GCC, главный "+" то, что бесплатно.. погуглите GCC на предмет поддержки ARM11.. GnuARM GCC

Доброго времени суток! Необходимо сделать шину PCI из встроенной в контроллер, шины PCI-express. Нашел следующие устройства от TI .. Скажите, возможно с помощью этой микросхемы сделать полноценную шину PCI через PCI-express для полноценной работы с PCI-устройствами?

Cпасибо за ссылку) Согласен. Задачу представил размазанно, сам это понимаю, но не хотел я вдаваться в подробности, принципиально... разве нельзя примерно (плюс-минус лапоть) прикинуть решение, чтобы перекинуть поток в 200Мбит с одного интерфейса на другой, и при этом что-то показывать на экране? (сорри за вульгарное изъяснение :beer: ) Насчет атома, согласен, перспективное решение.. Тогда я вообще перестаю что-то понимать, я думал главное преимущество атома - это полная совместимость софта х86, а значит он уже ARM-ам на пятки наступает по потреблению?

Работа - это одно, а опыт - совсем другое. Я никого не заставляю работать, на это есть своя ветка форума. Я просто прошу поделиться опытом и советами. P.S. Я лично не испытываю никаких отрицательных чувств от того, что я копался в какой-нибудь проблеме 2 дня, нашёл этот бит, к примеру :) а потом левому человеку за 5 минут рассказал, за что получил лишь такое полотно :a14: Все равно, мне эта работа на пользу пошла, чем я собственно доволен)) другое дело, если этот человек мой прямой конкурент, тут уже так не поступишь... зависть-такая-штука) 2All: По теме: Какое решение мне посоветуете для данной задачи, хотя бы примерно платформу?