User1285

У контроллера все остальные выводы заняты другими функциями, потому из доступных для общей связи остается один SPI.

Спасибо за предложение! Однако, к сожалению, нам нельзя привлекать к проекту сторонних программистов.

Да, именно так оно и будет организовано. Я наверное просто некорректно описал все. Смотрели в сторону ПЛИС, согласен что наверное было бы более правильно именно их использовать. Проблема в том что с ПЛИС ни я, ни программист не работали и потому время разработки вырастет в нереальные сроки.

Спасибо! Попробую гиперлинксом промоделировать. А вообще можете подсказать какие могут быть подводные камни в подобных решениях как у меня? Просто я до этого не сталкивался с такими скоростными шинами да еще и с таким кол-вом одновременно подключенных контроллеров на эту шину.

Каким образом правильно произвести моделирование?

Плата еще не разведена, я сейчас разрабатываю схему и мне нужно учесть там разные возможные нюансы...типа поставить дополнительные буферы, терминаторы на линии и т.п. Потому и возникает вопрос как бы это промоделировать сначала, потому что плату такую изготовить будет недешево стоить и потому не хотелось бы ее переделывать потом. Плата будет разводиться скорее всего в Mentor expedition.

Да, микроконтроллеры cortex M4 вполне нормально вытягивают такую частоту SPI. А не подскажете каким образом лучше всего это промоделировать? Специальным софтом (каким?) или на макете?

Добрый день! Возник вопрос - нужно на одну шину SPI навесить порядка 25-30 микроконтроллеров, которые будут работать в режиме slave. Мастер будет всего один (тоже контроллер). Работать они будут цепочкой, т.е. данные вошли в первый MOSI, вышли из MISO и пошли к следующему контроллеру. Тактироваться все будут от одного источника, так же и как CS у них будет общий. Так как контроллеров довольно много, то протяженность линии будет довольно большая - порядка 40-50 см, не меньше. Задержки при обмене данных должны быть минимальные, потому частота тактирования должна быть не менее 12 МГц. Первую проблему, которую я вижу это нагрузочная способность выводов SCK и CS - решить ее думаю использованием дополнительных буферов с хорошей нагрузочной способностью. Больше вопросов возникает из-за протяженности линий по плате (емкость проводников и т.п.) - каким образом избежать негативных последствий связанных с этим? Подскажите пожалуйста какие еще могут быть нюансы и как лучше решать связанные с ними проблемы? Спасибо!

Добрый день! При попытке использовать SPI-бутлоадер в контроллере STM32F401 столкнулся с проблемой - контроллер ведет себя не так как описано в документации. Для опытов использую отладочную плату NUCLEO F401RE и аппликейшены AN4286+AN2606. Использую SPI2 в следующей конфигурации: Slave mode, Full Duplex, 8-bit MSB, speed 1MHz, Polarity: CPOL Low, CPHA Low. Выводы портов: NSS=0, boot0=1, boot1=0. Сразу скажу что бутлоадер по UART1 работает нормально, т.е. ситуацию с тем что контроллер не переходит в boot-режим я отбрасываю. После сброса я посылаю контроллеру байт синхронизации 0x5A и ожидаю в ответ получить 0xA5 (согласно документации), однако получаю 0x08. Попытку послать синхробайт делаю несколько раз и только после третьего 0x5A я получаю в ответ 0xA5. Дальше судя по документации я должен послать 0x00 и ожидать ACK(0x79) или NACK(0x1F), но я сразу получаю 0x83. Я продолжаю "долбить" контроллер этим байтом 0x83 и спустя посылок так 200 получаю всетаки 0x79. Считаю вроде как что синхронизация закончена, однако посылая команду 0x5A 0x00 0xFF я должен получить ACK иkи NACK однако контроллер возвращает мне чепуху какую-то. Подскажите пожалуйста что я делаю не так? Спасибо!

Спасибо за ответ! С приведенными Вами аргументами действительно не поспоришь. Я согласен что для целей тестирования лучше использовать отдельную программу заливаемую через какой-либо из интерфейсов...она лучше сможет протестировать все остальные узлы в изделии. Тут есть еще один нюанс, который всплыл позже...к программатору также могут подключаться ( для смены прошивки или первичного программирования) изделия с другим типом контроллера (один из вариантов Microchip PIC32). Потому и стоит задача использовать jtag, чтобы использовать один интерфейс программирования для разных типов контроллеров, потому как PIC32 не имеет (в отличии от атмела) встроенного бутлоадера, первичное программирование нужно производить программатором либо через ICSP(фактически тот же jtag) либо через JTAG. Тестируемое-программируемое изделие будет подключаться к программатору через специфический разъем с кучей дополнительных контактов (для тестирования изделия), а прошивка в сам программатор будет заливаться удаленно нашими специалистами, пользователь не будет иметь возможности что-то там изменить. JTAG в изделии выводиться не напрямую а через специальные коммутаторы и таким образом он фактически защищен снаружи.

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

Проблема создания клона девайса не беспокоит в данном случае, т.к. сама железка не автономная, она работает в составе комплекса и толку с нее никакого нет отдельно от всего остального оборудования.

Все это здорово конечно, проблема в том что у меня стоит задача что именно мое устройство должно шить изделия по JTAG (во-первых это устройство должно быть дешевым, чего не скажешь про покупные программаторы, во-вторых будут использовать свои уже имеющиеся протоколы удаленной загрузки прошивки в программатор. Также имеются еще другие нюансы.) и варианты покупного изделия не рассматриваются. Потому я и прошу подсказать по поводу того есть ли описания атмеловского протокола работы через JTAG.

Спасибо за предложенные варианты. К сожалению такие варианты не подходят. Нужно сделать именно реализацию собственного программатора, т.к. в нем еще будет заложено удаленное обновление прошивки (обновление прошивки изделия, лежащей в памяти программатора). Память в изделии уже забита под завязку, потому варианты чтобы контроллер изделия обновлял сам себя не подходят.

Добрый день! Подскажите пожалуйста, имеется ли возможность программирования ATMEL ATSAM-контроллеров через JTAG ? Я имею ввиду открытость и доступность информации по JTAG-командам. Я не нашел ничего полезного, к сожалению. Мне необходимо сделать на микроконтроллере программатор, с помощью которого можно было бы шить установленные в изделии контроллеры ATSAM3N и подобные. Эти контроллеры можно прошить через встроенный бутлоадер, однако у меня наружу с изделия выведены только JTAG-и контроллеров. Программатор должен быть именно автономный, без ПК. Спасибо!

В Вашем случае для устройства В WOR не нужен, он больше нужен в случае если устройство ограничено в ресурсах по питанию. Устроство В пусть постоянно висит в приеме и слушает эфир. Он отвечает за то чтобы в любой произвольный момент времени принять пакет от датчика, обработать его и ответить датчику. Если смотреть в сторону ZigBee и городить чето подобное это только головную боль себе нажить. Определенные вещи можно взять оттуда, но отнють не все. Не советую делать В мастером и чтобы датчики просыпались и принимали от него запросы, получите головную боль с синронизацией. Проще привязываться к моментам приема последнего пакета от каждого конкретного датчика и уже от них, в случае необходимости, отсчитывать момент когда датчик следующий раз ответит(развивая это направление можно отслеживать пропадание датчиков проверяя периодически промежутки времени с момента последнего выхода датчика на связь). По поводу посылки параметров датчику - я тоже делал подобным образом...в памяти центрального устройства В хранились очереди команд для каждого датчика и когда датчик присылает пакет я смотрю нет ли для данного датчика управляющих команд и в ответном пакете подтверждения делаю пометку что для него есть управлющие данные и передаю их. Я просто изначально размер пакета сделал с запасом, потому мне не надо было передавать ему дополнительные пакеты. Сколько служебных(командных) байт Вы планируете ему передавать и какая у Вас длина пакета подтверждения?

Если я правильно понял, то устройство B у Вас со стационарным питанием. Зачем в таком случае использовать WOR. А от коллизии действительно удобно использовать псевдослучайную задержку перед передачей (прослушивание канала не дает особых преимуществ, если только два передающих устройства не находятся близко друг к другу...если же они находятся на разные стороны от приемника, то они могут друг друга и не услышать), время которой находиться в пределах, например, 0..0,5*(длительность пакета). Плюс, в случае если устройство А не приняло пакета подтверждения, то через какой-то промежуток времени оно делает еще одну попытку передать пакет, затем его отбрасывает(количество переповторов подбирается исходя из важности информации).

В настройках СС1101 есть флажок, который позволяет очищать входной буфер в случае принятия битого пакета(несовпадения контрольно суммы). Но для этого пакеты должны быть фиксированной длины и включена проверка контрольной суммы. Посмотрите в этом направлении. Какой у Вас формат пакетов? Фиксированная длина пакета? Один пакет помещается в приемный буфер?

Смотрели в сторону uCOS, однако по требованиям использованная в устройствах ОС должна быть либо бесплатная либо официально купленная, а uCOS в этом отношении неподъемная по цене к сожалению. Плюс еще ихний стек TCP/IP тоже ж нужно покупать, а он по цене еще дороже чем сама ОС. Я честно говоря сильно глубоко пока не вникал в harmony, но я так понял (возможно я неправильно понял) что он берет на себя нюансы связанные с тем чтобы тот же майкрочиповский TCP/IP стек работал с той же FreeRTOS, т.к. он же изначально не заточен под ОС. Собственно это меня и привлекло в harmony.

kolobok0, спасибо большое за столь подробные уточнения! Буду пробовать запускать. Менять контроллер к сожалению не в моих возможностях, не всегда исполнитель выбирает железо с которым ему работать. По поводу microchip - я смотрю они просто пошли немного по другому пути, не разрабатывают свою ОС а пытаються свои библиотеки соединить с уже имеющимися FreeRTOS-OpenRTOS (имею ввиду microchip harmony). К сожалению я так понимаю harmony еще очень "сырая" для ее реального использования.

Ну я так понимаю если брать OpenRTOS, то это ж платный продукт и теоретически багов должно быть меньше чем во FreeRTOS? Какую ОС Вы можете посоветовать с меньшим количеством багов под PIC32?

Спасибо за совет! Обязательно посмотрю!

Добрый день, уважаемые специалисты! Возникла задача выбора операционной системы для разработки устройства на базе PIC32. Устройство представляет собой своего рода преобразователь интерфейсов RS+SPI в Ethernet, плюс web-интерфейс для конфигурации устройства. Наличие RTOS является обязательным требованием. Соответственно возник вопрос какую ж выбрать ОС и какой TCP/IP стек к ней, чтобы это все нормально работало между собой и портировалось на PIC32. Смотрел в сторону FreeRTOS-OpenRTOS, с ними нужно использовать, как я понял, стек lwIP либо покупной от FreeRTOS(однако я не смог найти отзывов по нему, насколько он полноценный и нормально работает). Насколько это удачное решение? Операционная система желательно чтобы была не дорогая, не могу себе позволить дорогую. Посоветуйте пожалуйста в какую сторону мне двигаться! Спасибо!

На первый взгляд очень заманчивая штука. Единственное что смущает - учитывая ее новизну, можно предположить что имеет пока еще довольно много багов, стремновато ее использовать сейчас. :(

Добрый день! Прошу совета. Вкратце опишу суть вопроса. В своих устройствах использую микроконтроллеры различных семейств(PIC, MSP430, планирую для более сложных проектов перейти на STM32). В основном устройства не очень сложные. Сейчас возникла необходимость в разработке устройств с web-интерфейсом(для конфигурирования, просмотра логов и т.п.) а также устройства должны будут складывать данные на удаленный сервер, обновлять прошивку удаленно и т.п. Смотрел на микросхему W5100 со встроенным TCP/IP стеком. Запустить не ней простой web-интерфейс , насколько я понял, будет довольно несложно, однако смущает ее дороговизна и не сильно широкое растространение (я так понимаю ввиду ограниченности возможностей ее стека?). В результате этого пришел к выводу что все-таки предпочтительнее использовать софтверный стек внутри контроллера и простую физику снаружи(в случае PIC18F97J60 и подобных еще дешевле все получается, т.к. физика внутри контроллера). Уважаемые специалисты, посоветуйте пожалуйста новичку какой из стеков (lwip, или от microchip, или еще какой-то) мне лучше выбрать чтобы, так сказать, он был более универсальным, т.е. при необходимости его можно было портировать на разные семейства контроллеров? Или же предпочтительно остановиться на каком-то одном семействе для работы с ethernet?