pil123456789

В случае автора должно хватить

работает так же как и по отдельности реализовали эту схему. делали USB_FULLSPEED -device, USB_HSPEED - host. Работают они полностью независимо.

Протокол придумываем с нуля, ничего существующего нет. На мой взгляд при выборе протоколов стоит стремится выбирать из существующего, а не плодить сущности. Если мы связываем устройство каким либо образом с миром ПК, то подход избавляет от необходимости писать ответную часть протокола. >> Сделайте свой TCP сервер с нужным протоколом. Вопрос протокола и стоит >> Возьмите готовый сервер (MQTT например) и пробросьте порт. Спасибо. Это интересно, буду читать. >>Используйте http/https протокол с VPS за 20 руб в месяц. Это вопрос сервера. Свой или "облачный". Пока не стоит. >>Используйте открытый сервер для IoT (штук 20 в гугле найдутся на первой странице) А встречали такие, где не только красивая обертка, но и файло-передача логов и обновление прошивки?

Дело происходит на cortex-m. Так что без скриптов. Но здорово, что велосипед не мой. Интересует какие еще варианты возможны. Например, у колеги возникла идея проброса отдельного порта ввода вывода(в примерах tty) на сервере на порт tcp. Socat в linux вроди такое умеет, может и ssl. И общаются они через организованный псевдо последовательный порт. (Tty over tcp).

Здравствуйте! Есть вопрос, может кто сталкивался с подобной задачкой. Есть устройство на Cortex M3 c GPRS. Нужно организовать доступ к нему из интернета со следующим функционалом: 1. Обновление прошивки. 2. Постоянное получение текстовых логов работы. 3. Конфигурировать устройство. 4. Минимально управлять. Короткий список команд. Естественно хочется что то стандартное повозможности, минимум велосипедов. Единственное, что смог сам придумать, это: 1. Есть сервер FTPS со статическим IP 2. Устройство конектиться к нему и происходит двухсторонний обмен. Например есть папки IN и OUT. В одну складываем логи, из другой берем команды. FTPS, так как уже есть реализации и FTP и SSL для cortex. Доплачивать за static IP для устройства не хочется. Сталкивались с другими вариантами решения обмена по GPRS на кнтроллерах?

Про SPI понятно, как вариант. Второе - интерфейс внешний памяти, может некую двухстороннюю память между ними поставить? Или сделать FPGA - внешней памятью для контроллера? Да контроллер stm32f217, 7.5Мбод UART работает. CPU - stm32f217 120МГц - пока так. Хотелось бы распаралелить максимально, чтобы посылки в UARTы уходили одновременно. А можно объяснить в чем проблема поподробнее? Тоже думал об этом. Но опыта подобного нет. Программирую контроллеры, немного знаком с FPGA простенькими. Боюсь не потяну. + Спасибо всем за участие.

Спасибо за ответ. Все таки чем связать с контроллером? Там потом UART -> rs485. Расстояние 0,5-1м + помехи.

Скорость обусловлена задачей, как и количество абонентов. С количеством логических элементов будет понятно при моделировании на компе Интересен вопрос как соединить CPU <-> FPGA. отпадают всякие uart, spi. Вот думаю через общую память как то?

Нужна ваша экспертная помощь новичку в ПЛИС. Нужно выбрать ПЛИС (или несколько маленьких ПЛИС) Задача: 1. Обмен с контроллером, который получает данные по Ethernet. Я пока вижу это через какую то двухстороннюю память, но вопрос открыт. 2. Выдача информации на 17 Uart со скоростями 5-7Мбод 3. Получение информации с 17 uart, скорость не принципиальна. 4. Uart'ы fullduplex, т.е. 17 uart на вход и 17 на выход. 5. FPGA не сложно упаковывет посылки для uart (подсчет простеньких контрольных сумм) Вопросы: 1. Выбор FPGA 2. как принято осуществлять обмен FPGA<->CPU. Объем данных на выход ~50 байт CPU->FPGA (с высокой скоростью) на вход ~100-200 байт FPGZ->CPU (скорость не критична) Заранее спасибо всем сочуствующим.

Источник это пока теория, но точно не моя разработка, соответственно Ethernet стандартен. Rs485 5-10Мбод звездой - это просто 16 стандартных RS485 (точка-точка) Непонятно, что такое джиттер? А получится эмитировать 16 UART'ов? (SPI не так хорош, но можно и 16 SPI).

Ух ты, сколько ответили. Спасибо! 1. Нестандартный Ethernet не пойдет, т.к. этим выходом наша подсистема заканчивается. Странно в документации будет это описывать. Все делается как ОКР, не хватит 100Мбит - вижу тока вариант 1Гб сеть ну или что то последовательное типа LVDS. На данный момент 100Мбит Ethernet, до второй ревизии как минимум. 2. Дальше внутряння сеть RS485 со скоростями 5-10Мбод. Причем не стандартная шина, а звезда (в устройстве так надежнее/удобнее). Оконечниками будут STM32F205 (мне оно ближе). 3. На роль центрального узла Ethernet -> 16*RS485 думаю попробовать тот же stm32 + CPLD MAX V, на макетке попробуем успеет ли stm выплевывать. (может посоветуете через что их лучше соединить?). Не хватит stm, буду думать. Мощные FPGA для меня туманная тема. 4. Передача двунаправленная, но посылки RS485 -> Ethernet редкие. Думаю нужно ли закладывать фул дуплекс или хватит 1/2 дуплекс RS485.

Вопрос изменился. Оконечники стало ясно что можно сделать на контроллерах используя имеющиеся наработки. Теперь вопрос как сделать корневой узел. Задачи: 1. до 100Мб поток Ethernet (UDP) 2. 16 последовательных каналов со скоростью до 3-5 Мбод каждый В какую сторону смотреть?

Спасибо всем за ответы. Варианты значит такие: 1. FPGA c загруженым ядром+ там же формирование внешних последовательных интерфейсов 2. CPU с Ethernet 100 + (маленькая FPGA)/CPLD А какого уровня FPGA смотреть/пробовать? (уже не та ветка форума похоже)

100Мб - это поток(вероятно UDP пакеты), реально будет меньше ~30-50Мбод, но запас это хорошо. Суть девайса парсить этот поток и выплевывать информацию в 16 последовательных интерфейсов ~3-5Мбод. По ощущениям stm32 f107 не успеет. Может стоит смотреть в сторону Cortex M4? Интересует ваш опыт работы с загруженным Ethernet 100. Непонятно зачем конкретизировать физ. уровень, я пока выбираю контроллер.

Понадобилось прогонять через систему 100Мб, видимо UDP пакетами. От контроллера нужно лишь наличие мощи, чтоб переваривать 100Мб и отправлять в некий другой интерфейс. Чем иp ARM минимально можно обойтись? Работал тока с младшими stm32 и аналогичными LPC, они явно не тянут.