framer

Это справедливо не для всех многочленов а для многочленов в поле GF(q). Это общее правило разложения многочленов на множители. Но для поля многочленов GF(q) s(x) = 0 . Теперь если в данное разложение подставить бету то получим 0 т. е. корень.

оно? https://www.crowdsupply.com/great-scott-gadgets/luna

Да но есть один нюанс. Вот например хороший девайс SI5383 для подавления джиттера оптимизированный под 1PPS от GPSа. Кратковременный джиттера подавляет хорошо, но был замечен эффект джиттера с периодом 20 -30 минут. Понятно, что это зависит от многих факторов. От самого GPS, сигнала , антенны , атмосферы , и грузовиков с джамерами . И тут похоже без компромиссов. Либо делать подавление и фильтрацию с длительным периодом (несколько часов а может и день) либо при коротком периоде иметь неточную калибрацию. Но хуже всего, что при этом, не будет повторяемости.

Да капитальное устройство. У мня такой вопрос. Вот там у Вас стоит GPS для калибровки. Я так понимаю, что калибровка как по частоте так и по фазе? Т.е. 1PPS получаем абсолютный? Сколько времени необходимо на калибровку и как это коррелирует с качеством сигнала от GPS? Если не секрет какой GPS? Ublox-a? И еще вопрос. Какое отклонение 1PPS в режиме holdovera?

А точно Ucвх + Ul + Uc + IcR + Ucвых = 0 ? Может Ucвх = Ul + Uc + IcR + Ucвых ?

Прошу сильно не пинать. Возможно скажу глупость. А как с шагом дискретизации DDS? Попробуйте дать +1 / -1 после регулятора и посмотрите как измениться результат.

Роутеры это совсем другое. Все зависит от того что гоняем через роутер. Некоторые коммутаторы имеют функцию static routing L3 и могут вытягивать до 800/900M на 1G интерфейсах Но это если нет IPSec и все идёт через коммутатор. Если надо поток пропустить через хост процессор то все очень плохо. Для машин линукс какой бы не был производитель роутера, роутинг проходит через ip tables. Я измерял пропускную способность нескольких модулей SOM. Машина на SAMA5D4 на 100М интерфейсе показала производительность около 70М при чистом роутинге и 20М при IPSec. А вот такая машинка http://espressobin.net/ показала 400М при чистом и 200М при IPSec. Но они заточены под сеть. А вот на коммутаторе от Microsemi при чистом потоке 800М. Через пару дней буду иметь информацию по поводу imx8mm. Но роутинг это совсем другая тема.

Предварительный концепт нода. Хотел бы спросить/обсудить следующие конструкционные вопросы . Количество входов/выходов. Гальваническая изоляция РС485 и ЦАН Питание. Размеры Корпус Почему? Это только модель для проверки некоторых идей. Это не конечное устройство. Вот выше предложение как я это вижу, Если обсудить может и что нибудь получится :) А модель будет выглядеть так,

Ну во надыбал пару коммутаторов TP-Link LS105G 5x1Gb. Документация на чип есть. В целях «proof of concept» попробую сделать макетку. Для этой цели буду иметь пару вот таких https://kamami.pl/moduly-som/573098-visionsom-rt-modul-z-mikrokontrolerem-imx-rt-1062-sls12rt62528c0r4qspi0sfi.html евал боард . Управление MDIO вытягивается с коммутатора элементарно. Сигналы MDC MDI те же что идут на EEPROM. Надо только один сигнал подтянуть к земле. Подключение к евал борде будет пока отдельным портом а не через RMII но это на этом этапе не принципиально. Да вот и микротик эти коммутаторы поддерживает https://wiki.mikrotik.com/wiki/Manual:Switch_Chip_Features

Был один клиент. Обьект был большой. За основу был использован KNX от GIRA . Проблемы начались когда клиент хотел, чтобы на панелях интегрировать видеодомофон с системой видеонаблюдения и управления. Хотел поговорить через домофон с человеком перед калиткой. Открыть гараж или калитку, Покрутить камерой видеонаблюдения, Хотел чтобы все регистрировалось. Дубовый и дорогой homeserver https://partner.gira.com/en/systeme/knx-system/knx-produkte/server/homeserver.html от Gиры мог показывать только картинки с частотой отрисовки 1 секунду. Но надо было еще как то эти картинки с системы видеорекордера достать, Отдельно канал KNX, отдельно сеть ETH для панелей. Отдельно видеорекордер. Надо было везде тянуть свои кабели. Для видеонаблюдения свои для управления свои для видеодомофона свои. Ну если принять, что этот весь поток данных идёт одним каналом то хотя бы появляется возможность интеграции. Ещё была сигнализация периметра. Ну в данном случае можно было бы подключить через такой Нод IP камеру с PTZ для видеонаблюдения, IP камеру с микрофоном и динамиком как видеодомофон. Входа/выхода нода использовать для открытия электрозамка в калитке и кнопку вызова/звонка. Вот под такой сценарий по моему Нод и подходит. Поэтому и появилась идея одного канала. Да согласен. С рингом перебор. RSTP как раз то, что надо и топология сети получается гибкая.

С POE интересно. Беру идею к анализу. Проблема будет только с тем что даже в режиме пассивного PD надо будет делать конвертер PD na PSE. По простому запитать и перебросить на другой порт не получится, Но вопрос с питанием стоит рассмотреть. Интересно мнение на счёт целесообразности применения РИНГ. Этот стандарт очень сильно променяют сетевеки на уровне L2. У меня была практика реализации этого протокола на AVR32 с похожим коммутатором. Протокол очень хорошо ложится в такие коммутаторы. Там основная проблема в возможности блокировки портов по MAC и очистки MAC таблиц при определённых условиях переключения направления. Что мы с рингом имеем, Если обрывается соединение в любой точке перебоя практически не видно и все узлы работают и видят друг друга. Утеря пакетов есть но она не превышает 50 мс. На конкретном примере. Скажем по схеме выше Нод 5 и 6 находятся на втором этаже. Если в ринге происходит обрыв между первым и вторым этажом в одном месте то для пользователей и управления это даже не заметно. На втором этаже работает интернет и все функции УД. Типа этого. Если такая функциональность избыточная то наверное не стоит запариваться. Хотя функции коммутатора оставить надо а следовательно реализация ринга это чисто программная фича . А функцию коммутатора следовало бы оставить потому что поток транковый с vlan и приоритетами. Я это позже опишу как будет выглядеть поток данных и аварии если интересно. Тут фишка такая что не все заминались сетями а из этого можно много чего вытянуть. А интересно как общая идея использовать толстый канал для всех подсистем? На счёт IEC61850 то это как показатель не обязательно его использовать но обратить внимание стоит. Можно даже руками потрогать. Об этом тоже могу написать. Тут вопрос следующий . Для realtime обмена данными лучше использовать уровень L2 чем L3. Как соберу мысли то напишу. Да это одно из решений. В похожих ценах есть много решений. Есть тяжёлые клиенты но пробивные. Я как раз имел дело с Marvell. У них конечно мох и болото. Есть варианты с SERDES. Можно ставить каналы под SFP. Если постараться то можно достать. Ну и Microsemi pod Microchip легла и открылась. В общем выбор есть. https://www.microchip.com/wwwproducts/en/KSZ9897 http://ww1.microchip.com/downloads/en/DeviceDoc/KSZ9897S-Data-Sheet-DS00002394C.pdf

В очередной раз встретился с людьми которые хотят создать у себя УД. Обращаются за советом чтоб им посоветовать. И уже какой раз у меня появляется идея заняться этой темой вплотную, но не решением конкретной задачи под конкретного клиента а поиском ниши для создания базовых устройств. Пересмотрел информацию по поводу решений, пересмотрел проблемы и появилась идея. Но сначала хотел подытожить холивары по поводу решений и проблем. Холивары Системы централизованные /децентрализованные. Орган управления плк /пц. Сеть Проводная/ беспроводная. Проблемы Пропускная способность каналов связи. Если иметь толстый канал то можно пустить всю информацию через этот канал. Интернет, Аудио, звук, управление. Надежность каналов связи. Обрыв канала в одном месте обеспечивает полную работоспособность системы. Жесткий realtime. Обсуждалось. Появлялись цифры около 20мс. Была информация на счет EtherCat что это очень realtime но канал должен быть выделен только под него. Масштабируемость системы. Устойчивость функциональности к аварии части системы. Падение любого элемента системы не приводит к ступору. Возможность выхода вверх (облачные сервисы). Закрытие канала WAN не сказывается на функционале системы локально. Подумав над проблемами появилась идея создать что-то на подобии backbone сети с элементами которые обеспечивают работу и постараться использовать стандартные решения. Если присмотреться то похожие проблемы есть на цифровых подстанциях 61850. Там есть и толстый канал (process bus) с выходом вверх (goose protocol) и realtime(sv protocol) (передача до 4000 измерений на секунду от одного устройства). Также применяется технология G.8032v2 ERPS (Ethernet Ring Protection Switching ) . Так что первое что пришло в голову использовать в качестве основного канала связи 1G ETH и закольцовать в ринг. Элементом этого кольца будет Нод. Нод это такой автономный ПЛК со встроенным коммутатором на 3 порта 1G . Основные функции нода, это отработка например загруженной программы согласно с IEC 61131-3 стандартом. Обмен информации с соседними нодами если переменные выходят за пределы одного нода (sv protocol типа iec61850_9_2_LE ) и обслуживание ринга. Так как нод содержит коммутатор то без проблем можно подключить или компьютер или камеру. Это будет единая толстая бесперебойная транковая сеть в УД. Разделение vlan-ами позволяет отделить интернет от управления. С нодами похожее решение есть в KNX, там встречаются такие ноды что с одной стороны обслуживают магистраль KNX а также имеют по несколько входов/выходов а с другой имеют внутреннюю магистраль для подключения специфических актеров/сенсоров. Схема будет выглядеть приблизительно как на рисунке. Т.е. получается, что основная разводка проводов это в основном качественный кабель для сети CAT 5 / 6 и питание. Если поставить ноды в одном месте то будет система централизованная и эти ноды будут выглядеть как один ПЛК. Если разнести модули по этажам/ помещениям получается система децентрализованная. Если модуль упадет то перестанет работать только этот модуль и часть функционала с внешними состояниями. В качестве Eadge device можно использовать PC с OpenHUB. Если проблема с расстоянием можно использовать fiber (например видео домофон во дворе). Почему 1G? Ну в основном чтобы можно было гонять несколько потоков видео и работать с интернетом через эту сеть. Используя QoS i vlan можно управлять приоритетами и достигнуть realtime для канала управления даже с загруженной сетью. Это в общих чертах. Ну сколько бы это стоило? Идея появилась после предварительной грубой оценки цены. Из тяжелых элементов это шустрый MCU + коммутатор + питание. На пример rt1064 + KSZ9897 + AC/DC 5W ~ 40$ + остальная часть 40$ в сумме такой нод должен получится около 80. Ну и конечно куча работы. Хотя с большой частью технологий я работал но и так всего самому не переделать. Есть идеи и наработки. Я сторонник открытых решений так что, если идея чего то стоит, то попробую более качественно описать и прозондировать на https://hackaday.io/ и запустить на https://www.crowdsupply.com/crowdfunding . Хотелось бы услышать мнение спецов особенно AlexandrY i syoma ну и конечно всех остальных.

Вот наткулся. https://forge.codesys.com/trg/raspberry-pi/wiki/Home/#realtime-patch

Да KNX это архаизм и магистраль медленная и интеграция с остальными системами плохая и видео идет боком, но некоторые концепции стоят того чтобы на них обратить внимание. Минусы тут уже описывали. А вот из плюсов только распределённость. Да KNX чем то похож на CAN. Решает проблему общего доступа к каналу и не требует поолинга, но что надо сделать, чтобы принять подтверждения исполнения операции от всех заинтересованных узлов быстро не перегружая магистраль. В КНХ реализован интересный патент (групповое подтверждение с доминантным уровнем ошибки). Следующая интересная идея сегментации сети. По сути при очень маленькой скорости магистраль работает с очень маленькими задержками. Ну и еще как мне кажется способ реализации питания, устойчивость к низкому качеству проводки и длина сегмента магистрали. Если говорить о распределенных системах, то не знаю, что может быть лучше. На сколько критическое требование иметь распределенную систему при реализации УД не знаю, но проблем с такой системой появляется много.

Возникла проблема с AVR32 (AT32UC3A0512). Точная ситуация описана http://asf.atmel.com/bugzilla/show_bug.cgi?id=3021 . Случай 1, deadlock появляется когда часто высылаю пакеты. Может кто сталкивался с подобными проблемами?

Так в этом cube ST и предлагает в качестве стека TCP/IP LwIP.

А при чем тут Wi-fI?. LwIP это стек TCP/IP. Сопряжение с контролером MAC это аппаратно-зависимая часть и если нет готовой надо писать самому. Работоспособность во многом зависит от платформы и настроек а сам стек нормальный. Можете спокойно протестировать на PC в качестве платформенной части используется библиотека winpcap.

а какой manager памяти? #define configTOTAL_HEAP_SIZE ( ( size_t ) ( 24 * 1024 ) ) используеться в heap_1.c и heap_2.c . При обертке heap_3.c берется скорей из проекта. Точно не знаю может из файла stm32f40x_flash.icf (define symbol __ICFEDIT_size_heap__ = 0x200;)

Ну а как обяснить показатели использования стека uxTaskGetStackHighWaterMark под Win32? Заняло по 5 блоков(слов) и все. Видно, что стек в задачах не используется. Все зависит от того как перенесено на WIN32. Под win если посмотреть то таски симулитуютя использованием thread. Там нет переключения контекста с изменением указателей стека. Осуществляется это остановкой текущего thread и запуском следующего (можно посмотреть исходники в prvProcessSimulatedInterrupts ). В таком случае локальные перемнные не распологаються в стеке задачи FreeRtos, а используються механизмы win32. Поэтому отладка стека эфективна на конкретной платформе.

Видно, что в некоторых местах стек практически весь использован. Да размер стека выделяемый под задачи зависит от платформы так, что на эмуляторе может все работать.

А проверяли использование стека сомой таской? Сколько выделяете стека на таск xTaskCreate(task, (signed char *)"task", ??? , 0,tskIDLE_PRIORITY + 2, NULL); ? Как я писал локалные переменные ложаться в стек задачи а у Вас локальная переменная во uint32_t q[500];. Попробуйте динамически выделить память, либо сделать глобальную переменную и посмотреть как себя ведет. А что возвращает uxTaskGetStackHighWaterMark( xTaskHandle xTask ); во вложеных функциях ?

А может еще зависит от размера стека для конкретной задачи. В этом случае, это не только количество вызовов функции в глубину но и размеры локальных переменных в этих фунциях. Чтобы точно знать, что переполняеться стек задач надо использовать функцию http://www.freertos.org/uxTaskGetStackHighWaterMark.html

Спасибо заработало :)

Буду пробовать. Наверное при инициализации не делается halt. Может какой то скрипт надо выполнить? А может конфигурация openocd не та. Запускаю так: openocd-0.6.1.exe -f ..\scripts\interface\stlink-v2.cfg -f ..\scripts\target\stm32f4x_stlink.cfg Open On-Chip Debugger 0.6.1 (2012-10-07-10:34) Licensed under GNU GPL v2 For bug reports, read http://openocd.sourceforge.net/doc/doxygen/bugs.html adapter speed: 1000 kHz Info : clock speed 1000 kHz Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints Info : accepting 'gdb' connection from 3333 Info : device id = 0x10016413 Info : flash size = 1024kbytes Warn : acknowledgment received, but no packet pending undefined debug reason 6 - target needs reset Error: Target not halted Error: failed erasing sectors 0 to 4 Error: flash_erase returned -304

Для предыдущих STM раньше брал из Atollic. А с версии 3.1 сделали так что работает только с GDB из пакета Atollic. Там есть авторизация в начале сессии. С openocd отладка работает но ,что то не получается запись .elf во flash. В связи с этим есть несколько вопросов. Может кто нибудь поделиться gdbserver из Atollic 3.0.0? Как научить openocd перед запуском GDB писать .elf во flash? А может есть еще какие нибудь gdbserver для st-link/v2?