Видимо не особенно нужны :) Почти готовое решение - преобразователь USB-SPI (на FT232R например или CH430 [кажется так]) + небольшая схема на рассыпухе (двойной одновибратор, D триггер и несколько логических элементов)
Теоретически да. На практике туда подключают UART (с NRZ). Хотя у меня не такая большая практика, так что из чистого любопытства - кто нибудь знает какой нибудь пример использования RS-485 физического уровня совместно с чем либо, отличным от UART'а? Мне правда очень интересно
Вы в курсе, что 'кодирование манчестер 2' к 'данные нужно закодировать для обеспечения безопасности' не имеет никакого отношения? Манчестер это кодирование физического уровня, а 'обеспечение безопасности' лежит выше (как минимум на транспортном). Физический уровень у RS485 свой, и с манчестером он не совместим (точнее можно физическую кодировку манчестера зафигачить в RS485 линию, но это будет нечто совсем нестандартное - и не RS485 и не манчестер)
Да будет срач! 4 года прошло, можно всё по второму кругу обсудить :)
Async подход хорошо прижился в Python 3 и JS (парочка async/await). Но там очень помогает собственно интерпретатор - он берёт на себя заботу по преобразованию последовательного кода в машину состояний (по сути). От программиста требуется только разметить асинхронный функции (async) и точки их вызова (await). Но даже для такого упрощённого использования уже видно, что превратить чисто последовательный код в асинхронный просто так не получится - как минимум эти 2 волшебных слова придётся проставить везде.
Ни С ни С++ не предоставляют такой возможности (async/await), так что приходится кишки кода разматывать вручную.
У асинхронного подхода есть одно неоспоримое преимущество - количество точек синхронизации может быть любым (они ресурсы не тянут), для thread'ов придётся заводить отдельные thread'ы для групп таких точек.
Условный пример - web сервер для одновременного обслуживания 1000 клиентов, построенный на thread'ах (чисто последовательный - по штуке на thread), будет нуждаться в 1000 thread'ах. Асинхронный всё уложит в один thread.
2 направленные шины (как у вас данные) реально в FPGA не существуют. Синтезатор раскладывает цепи чтения и записи данных на разные провода и вставляет реальный буфер, подключённый к ним.
Поставьте этот буфер явно и разделите направления чтения и записи - тогда они будут реальными сигналами и chipscope их увидит
Во первых почему у вас в iconv.exe.exe с двумя exe?
Во вторых туда, куда вы его прописали, прописывать не стоит. Его должен вызывать сам gcc при работе. Так, как написано (после исправления .exe.exe) будет просто вызываться iconv без параметров
В третьих попробуйте положить ваш iconv.exe (вместе с dll) в каталог, перечисленный в переменной окружения PATH. Возможно заработает
Схема очень похожа на стандартную схему входных каналов гальванически изолированных приёмников сигналов (различная пром автоматика, типа PLC, драйверов двигателей и пр).
Там резистор и конденсатор ставят для подавления помех на длинных входных линиях (в отключенном состоянии). Конденсатор защищает от коротких выбросов (наводок), к резистор обеспечивает нагрузку для рассеивания энергии помехи (что бы она не в светодиод оптрона уходила), а так же обеспечивает пороговую характеристику схемы
Восхищаюсь настойчивостью и работоспособностью starter48 - если судить по количеству выложенных патчей, то он уже вполне мог написать PCAD с нуля
Снимаю шляпу
Вам совершенно конкретно ответилди уже дважды
Не получили. При идеальном перемножении (без искажений - чисто математически) гармоник не будет.
Будет сумма и разность частот
Именно
18 KHz + 4 KHz и никаких гармоник
