Nemod

Необходимо разработать прошивку для микроконтроллеров серии STM32F105, пожелания: - опыт работы c контроллерами STM32 - знание стандартной периферии микроконтроллера и цифровой схемотехники - умение осциллографом и паяльником найти и исправить косяки на плате - опыт разработки загрузчиков, обновления прошивки - язык Си, среда IAR, контроль версий GIT - опыт разработки протоколов и аппаратно независимого кода - устройство для работы в автомобиле, поэтому желателен также опыт и возможность работы с CAN, LIN - приветствуется знание finite state или event-driven программирования, MISRA С - работа по ТЗ, прототип есть, оплата сдельная (по договору), поэтапная, начинать можно сейчас - объем работы оценивается в 4-6 месяцев, скорее всего с продолжением и поддержкой проекта в будущем - работа удаленная, компания находится в Москве Первый этап - разработка и согласование протокола для последовательного интерфейса (мастер-слейв), который бы обеспечивал возможности согласно ТЗ - разработчика загрузчика который принимает и сохраняет прошивку по протоколу на внешнюю флешку (MX25L…), с дальнейшим обновлением основной прошивки - базовая пустая прошивка с инициализацией периферии - минимальный функционал с трансляцией состояния GPIO с одних входов на выходы - проверка правильности работы текущей периферии согласно ТЗ и замечания по схемотехнике если есть - результат работы - документация на протокол (описание кадра и реализованных команд), минимальная инструкция по сборке и заливке прошивки с загрузчиком, исходники в GIT репозитории Присылать резюме в телеграму/вотсап или звонить по телефону +79165229057 Владислав

Смотрите бит AT91C_EMAC_BNA, если такое случилось лучше очистить весь приемный буфер (я обычно просто выкачиваю все пакеты оттуда, recieve пока есть пакеты буфере) и сбросить этот бит AT91C_BASE_EMAC->EMAC_RSR |= AT91C_EMAC_BNA; Остальные приемы которые раньше я делал типа переинициализации периферии не помогали. Вообще в сетях где много мусора (смотрите снифером wireshark), забивается буфер 16-32 кб довольно быстро (2-4 мс при трафике 60мегабит/с например, 1,5 - 3 мс считая фрагментирование данных по 128 байт). Если пришел пакет срочно его выгребайте из DMA буфера. 50мгц это очень мало для работы с Ethernet.

Базой данных я назвал собственно набор угошников и футпринтов. Которые в оркаде хранятся в виде файлов в каталогах. Это же и есть ваша база данных. И вот с ней надо работать через ODBC, а не через проводник. В нашем случае Windows explorer (если точнее Windows API для файлов) тоже является средством доступа к БД, только он разрешает проблеммы совместного доступа на уровне файлов (файл == одна запись в БД). Но проблемма в том что у оркада один файл соответвует нескольким записям. И ещё через с оркадом можно было бы нормально работать с БД на уровне файлов, если бы перед сохранением компонента он заново загружал файл с источника (на тот случай если его уже кто-то добавил новый компонент или отредатировал ваш, пока вы правили компонент), помечал его признаком только чтения (на время сохранения), вносил изменения (разрешал конфликты если они есть) и сохранял. Сейчас он сохраняет olb файл видимо прямо из своего ОЗУ не проверяя внесли ли в него изменения пока он был открыт у вас. Пока работаем через расшаренную папку. Вообщем то для небольших фирм годится, но на корпоративное решение не тянет :(. Кто нибудь знает Capture будет когда-нибудь под линух? или надо под HDL переходить?

Ну конфликты в исходниках возникают крайне редко, т.к. Уровень декомпозиции на файлы другой. Здесь же ну допустим разбиты у вас компоненты на файлы по категориям (диоды, транзисторы и тд) . Высок риск что два человека добавляют в один и тот же файл компонент. Была проблемма когда я запихал БД в свн. Central library воспринимал подкаталоги svn как часть этой библиотеки и выдавал всякую билеберду. DxDesigner/Expedition flow. EE 2005 вроде. Про альтиум не знаю. Может быть. И что svn там не только для исходных текстов vhdl/c++ применяется? В любом случае svn для этих баз данных это на крайний случай. Правильнее бы было работать через odbc. Кстати если порытся на сайте то можно и найти эти проблеммы совместимости svn и expedition http://electronix.ru/forum/index.php?showt...p;hl=Subversion

Во. Можно поподробнее? Я предполагал следующую схему: 1. Создать репозиторий на сервере SVN для библиотеки 2. Закоммитить туда каталог со всей фигней (футпринты, олбэшки и т д) 3. Каждый пользователь для обновления своей локальной БД делает update в настроенную для Capture/PCB Editor директорию (я думаю в пределах компа проблемм с переносом не будет). 4. Пользователь может локально внести изменения и закоммитить их затем на сервер. Но возникают вопросы, как то - 2 пользователя подправили один olb файл, естественно первый его закоммитит, а у второго возникнет конфликт при попытке обновится (иначе не закомитится). Естественно как то разрешать конфликты в SVN удобно только для исходников, а что делать здесь??. Нет ли проблем со служебными каталогами .svn (если кто-то использует subversion)? Может лучше GIT? Пытался когда то реализовать эту схему для ментора, тот вообще ругался на .svn каталоги. Также одна из причин то чем плох альтиум для использования его с системами контроля версий это его огромные размеры файлов.

Все какие-то общие фразы, типа наш продукт лучше и поддерживает те и те интерфейсы. Ну вот что он выверяет? номиналы, названия. И нафига на начальном этапе наполнения БД это нужно. Вопрос не в том что ODBC, а что она там по этому интерфейсу ODBC сохраняет. Падстаки, футпринты она по нему сохраняет, символы компонентов? Вот чего я не нашел. Какое взаимное влияние при вставке может быть? мы же открываем на чтение компонент когда его вставляем. Основная проблемма совместное редактирование одной и той же библиотеки. И вообще крейг в книге вроде как заявляет что желательно не трогать структуру каталогов с компонентами, которая хранится локально, а как сделать чтобы пады, футпринты, olb хранились на сервере?. Сколхозить то я что нибудь могу, но хочется услышать как это сделать правильно. Попробую почитать их мануал по этим продуктам, но из флаеров так и не понял что они реально это могут сделать.

Хотим перейти на Orcad/Allegro. Пока конечно мало о нем знаю (почитал по диагонали Kreig Mitzner и прочие доки). Встал вопрос об организации центральной БД компонентов используемых в изделиях предприятия. Как это лучше сделать для "Orcad Capture -> PCB Editor" Flow? CIS я так понял это просто надстройка содержащая ссылки на файлы падстаков и OLB. И если это так то сложно его назвать базой данных, это просто представление данных которые валяются в виде файлов и редактирование происходит вообще не через него (может я чего-то не нашел). Сейчас основная идея вынести файлы на сервер и там их редактировать, но возникает тогда проблема совместного доступа. Т.е как разрешить конфликты совместного редактирования OLB файлов? И есть ли возможность хранить данные как-то в другом виде например в БД в виде BLOB полей или таких же файлов но чтобы конфликты доступа разрешал сервер?

Ну масштаб идеи я оценил. Колибри пока что более чем курьез не воспринимается http://lurkmore.ru/MenuetOS. И что хочется сделать процессорозависимую ось под ARM на асемблере? которая бы все реализовывала все потребности в маршрутизации и фильтрации трафика? Нет ну можно конечно, только не пойму почему на Си не написать. Во первых она будет переносимой, во вторых ну только в полтора два раза только больше места занимать. По скорости сомневаюсь что можно выиграть. Зато можно хоть как то вменяемо прописать уровни абстракции такой сложной системы, документацию сделать. Код легче поддерживать и потом проще делегировать разработку другим людям если делать свою контору или открыть его. Что то сомневаюсь я что самые крутые проекты для этого дела типа Cisco IOS и JUNOS написаны на асме (ну может быть только небольшие вставки). Скорее всего они и C++ используют местами.

Ну я сказал для начала "что то" из iMX, а не конкретно iMX287. Но вообщем я согласен что iMX с несколькими MAC это лучше чем sam9xe с одним. Ему нужен шлюз а не аппаратный свитч. Что он конкретно под словом шлюз имел ввиду, т.е. какого уровня обработка пакетов (MAC, IP, TCP, Application) идет он не сказал. Линукс это линукс, и большая пропускная способность при программной обработке на линуксе ему доступна только в некоторых случаях аппаратно решаемых встроенными в SoC модулями. Если нужен линукс и не заморачиватся на железе пускай идет покупает модуль PC104 или miniITX.

Вообще реальные пацаны делают все на одном кристале как например broadcom :) Правильный и дорогой подход - управляющий контроллер + плисина в котрую загрузить пару ip блоков mac mii + пара phy типа rtl8201 + всякая разная память озу типа ddr для организации очередей и буферов, nand flash если управляющий контроллер не может хранить у себя весь код плисины. Потом пару лет и три программиста и вот мы уже почти конкурент циске или джуниперу. Причем возможно с конкурентной ценой. Неправильный и подешевле - взять предлагавшийся ранее sam9xe512 или что- то подобное побыстрее например из iMX серии. На одну строну которого прикрутить rtl8201 на другую cp2200. Залить туда uIP или lwIP и дописать софт. После чего убедится что ты все равно не конкурент для длинка или негиара по стоимости и производительности.

Кроме TXD/RXD ничего не используем. На момент подключения USB переходника я драйвером вообще не управляю им управляет Виндовс. Может быть вы правы и нужно просто на самой железяке переставить джамперы или софтверно отключить все остальные управляющие сигналы которые винда может просканировать. Завтра попробую.

Ситуация в следующем (встречаюсь с ней уже не в первый раз): Имеется набор разработанного оборудования общающегося по RS-485 интерфейсу. Подключается это все к компьютеру с Windows через переходник в 232. Но! при этом Windows не является мастером, т.е. выполняет роль слэйва или полноправного участника (в мультимастерном протоколе). Естественно в таких протоколах при загрузке виндовса или при втыкании USB адаптера (485->232) на 232 ком порт валится куча разных данных, которые виндовс по каким-то своим методам интерпретирует как данные от Microsoft Mouse или TrackBall. И естественно инсталлирует сразу драйвер этого трекбола, который занимает ком порт :) Ситуация комическая но представляет очень серьезную проблему для будущих пользователей :(. Причем проверено это на двух совершенно разных протоколах, что наводит на мысль что исправление протокола не исправит эту ситуацию. Пробовали править boot.ini с опцией /fastdetect но для USB преобразователей это не подходит, а COM порты в современных компах можно и не найти. Пока единственный придуманный выход это загасить Plug'n'Play на компьютере что совсем не красивый выход. Что делать?

Да я читал это, просто в момент пуска даже допустим 400 ом не перетягивают, в течении 1 мс, потом все нормально.

На всех схемах где я использовал sam7x есть интересная особенность, то ли это особенность камня, то ли обвязка такая. Собственно проблема вот в чем: В момент включения схемы происходит переход всех выходов портов (ну или множества я все не проверял) в высокий уровень 3.3В на 1мс. Этот уровень нельзя перетянуть никаким резистором (ну 10 ом перетягивают, но так работать нельзя). Проблемма не софтовая в свое время проверял её с начисто стертой флэшкой. Соответственно после этого взбрыкивания ноги как им и положено переходят в третье состояние. Кто-нибудь сталкивался с таким? или может где-то в даташите я это упустил? Просто уж очень много крови выпила данная особенность этого проца :(

Это и называется распределять средствами. Вы распределяете средствами линкера для чего пишите соответсвующий файл типа xcl, icf, xml, sct и т д и т п. Для этого вы вынуждены изучать документацию на линкер при переходе на другой и тратить на это время. Стандартные методы это ANSI C/C++.