jcxz

Так видимо просто TX на этом FT232 подпалён. Замените. PS: Можно ещё проверить достаточность напряжения питания Vbus приходящего на FT232. А то может там далеко не +5V.

Что "надёжный" и что "везде". Вы разницу с "у меня" и "везде" понимаете? Отучайтесь говорить за всех! Или вы проверили его работу на всех ПК в мире во всех системах? Из моей практики PL2303 - вещь крайне глючная и ненадёжная. На больших скоростях и больших непрерывных потоках данных через порт наблюдал периодические потери символов. Поэтому я вообще перестал его использовать где бы то ни было. Да и Harbinger как видно не в восторге от его работы. А вот CP21xx и FT232x - работают без нареканий в любых условиях много экземпляров.

Причём тут си? ТС хочет "на человеческий"!

Попробуйте соединить TX с RX на FT232 и проверить приём передаваемых данных. PS: МК конечно нужно отключить.

Сомнительно. Но даже если это так, то какой выбор у производителей МК? Убрать с рынка все дешёвые (с малым ОЗУ) МК с ETHERNET-ом? Это и экономически нецелесообразно (для потребителей МК). Да и технически (для решения прикладных задач) тоже нецесообразно: так как слабые МК - обычно малопотребляющие, замена такого МК на более мощный с бОльшим ОЗУ в проекте неминуемо ведёт к росту потребления МК, что плохо для тех задач, где требуется малое потребление. Ладно: допустим все производители сделали это (производят только ETHERNET-МК с большим объёмом ОЗУ). Но один из производителей додумался оставить дешёвые МК с ETHERNET в своей линейке и, для возможности подключения к ним браузера (с HTTPS only), создал в сети бесплатный сервис, который позволит через некий механизм/шлюз коннектиться к таким МК из браузера по каналу с шифрованием, но с ограничением всех возможностей HTTPS неким минимальным набором, который не потребует больших ресурсов от МК (само чисто шифрование (какой-нить единственный AES256 + единственный SHA256) на МК не требует больших объёмов ОЗУ). После этого аналогичные сервисы появятся и у других производителей МК. Другой путь: создание некоего отдельного протокола а-ля "light weight HTTPS", также с ограничением всего многообразия шифрований и генерации ключей неким минимумом. И поддержка его в браузерах (или в аддонах к ним). Вобщем - если есть потребность, то решение всегда можно найти. Это требования конкретной реализации алгоритмов для HTTPS. А кто сказал что нельзя меньше? Что это решение - не избыточное? Насколько я знаю - HTTPS позволяет согласовывать между клиентом и сервером параметры шифрования/генерации ключей и т.п. А значит сервер может указать как поддерживаемые только минимально-необходимый набор параметров (при том условии что браузер работает на жирной системе и умеет всё). Сколько нужно ОЗУ для такого набора? Вам известно?

Вы это реально наблюдаете у себя? Или где-то вычитали? И на какой именно ОС? За последние пару десятков лет не наблюдал такого ни на одном компе из множества за которыми работал. А уж COM-портов (разных, от встроенных в мат.плату или на PCI-плате, до разного рода виртуальных) у меня во всех системах = десятки. И использую их часто и весьма активно. И в разных режимах. Может у вас в системе были установлены какие-то специфические драйвера? Или явно (не по умолчанию) установлена сериальная мышь?

Ложь.

А где вы сумели найти мышь на RS-232 в нонешнее время?

В общем как всегда: не дедушка, а бабушка, и не продал, а купил... а в остальном всё верно.... Это называется - пинание колёс. Что-то тыкал, тыкал, пока вроде не перестало глючить (на данном конкретном столе). Что-почему - не понял и что завтра опять не начнёт глючить - уверенности никакой.... А памяти там может в реальности использоваться гораздо меньше, просто из-за фрагментирования кучи оно так работает. как работает....

Если предположить, что у ТС-а через TCP-сокет идёт поток данных со скоростью 1МБ/с и возможны задержки ACK-ов до <0.05c (без торможения потока), то на передачу нужно помнить = 1000000*.05 = 50кБ (в памяти TCP-сокета). А желательно и несколько больше (на случай редких ретрансмиссий). Но у ТС-а не 1МБ/с в реальном времени.

Ок, как утверждается здесь: https://tls.mbed.org/discussions/crypto-and-ssl/memory-consumption-32-kb-memory-buffer нужно 32кБ. Ещё куда ни шло. Но всё-таки это не 180кБ. А как бы в ~5 раз меньше. Разница есть и существенная, не находите? Но так и не ответили на вопрос: "Зачем нужно ~56 сетевых буферов"??? Для какой такой надобности? Я понимаю когда нужно передавать через TCP-сокет кадры прикладного протокола на большой скорости (без ожидания ACK-ов). Тогда да - нужно хранить длинную историю. Но в задаче ТС-а большая скорость совсем не требуется. Или если имеем сервер со множеством параллельных активных соединений. Чего вроде тоже как у ТС-а не наблюдается. Или "буфера сетевые" используются функциями TLS (шифрование? подпись? ...), а не только TCP/ETHERNET-стеком? Для "просто математики" 100кБ - как то жирновато. Слишком. Подозреваю, что стек у вас используется в качестве памяти для функций шифрования. Но тоже имхо - как-то слишком жирно. Вы лучше объясните - зачем: И что такое "буфера сетевые"?

И что именно в TLS требует 180 кБ? Причём: это видимо буфера под Ethernet-фреймы? И какое отношение имеет наличие TLS к их объёму? Неужто для TLS реально нужно иметь буфера для 80*1024/1450 = ~56 Ethernet-кадров???

Это новая кубо-реальность. Вангую скоро уже будет требоваться не менее 1 МБ. Пока что ещё не только "когда-то": у меня в текущем проекте мой стек работает на <10кБ ОЗУ для сетевых буферов (одновременно: 2 открытых TCP-сокета + 1 UDP). И это работает на стеке <900 байт - стек для всех сетевых задач (включая HTTP). Раз скомпилилось, значит есть. Только видимо она вся целиком на это дело и ушла. И на прикладные задачи остались крохи. Так и получается, что для опроса простого удалённого датчика, по нонешним временам, нужен как минимум - конский Cortex-M7 с максимумом ОЗУ.

Уже даже продаваны не понимают разницы между битами и байтами. Немудрено, что начинающие их постоянно путают....

На таких частотах я бы думал не о фильтрах, а о том чтобы обеспечить для SCLK такую же задержку распространения, как и для MOSI. По всей цепочке ведомых. Как у вас SCLK заходит в слэйвы: параллельно в каждый или последовательно (проходя через каждый ведомый)? И учитывается ли задержка, вносимая в MOSI/MISO всей цепочкой ведомых на входе в MISO мастера? (периферийные SPI-блоки некоторых МК имеют возможность компенсации такой задержки для высокоскоростных режимов). PS: По последнему вопросу ТС-ше хорошо бы проконсультироваться со своим программистом МК (если конечно SPI-мастер - на МК). PPS: Даже 20МГц в режиме Daisy chain может быть уже критично для работоспособности схемы в некоторых случаях. Например: при наличии в цепочке ADUM-ов для гальванической изоляции.