tonyk_av

Строчка с комментом любезно оставлена, кому надо, тот задумается и выберет нужный ему вариант, тем более после наших записей. У меня (пока) слэйв один, так что CS для него оставлен для развития, на будущее, впрочем, как и ещё парочка ног.

Нет. Ножка у МК занята другой функцией, поэтому CS для слэйва управляю программно с другой ноги.

AlanDrakes, теперь и у меня заработало. Сделал обработку флага готовности к передаче как у тебя- и взлетело. Благодарю! А вот это зря закоментарил. Без этой настройки SPI как мастер работать не будет, зато будет вылезать ошибка MODF и прерывание. Просто не активируй аппаратную функцию NSS на ноге при конфигурации выводов, чтобы SPI её не дёргал.

STM32F767ZIT6U SPI2, выведен на эти ноги:

Смысл? Подожду тех, кто работал с F7.

Да, я догадывался об этом. :)))) Я ведь не просто так прошу именно для STM32F7. У F4 и F7 эти интерфейсы отличаются, достаточно глянуть структурные схемы, и алгоритм работы, который работает на F4, не работает на F7.

Коллеги! Ткните в пример работы с SPI на этом МК без HAL. Вроде, делаю всё как написано в RM, но не могу добиться чтения. Хотя бы по байту, но если есть с DMA, то тоже будет хорошо.

Очень плохая задумка отправлять Модбас-сообщения через очередь. Размер RTU 256 байт, TCP 260. Даже на "жирных" в части ОЗУ МК это очень расточительно. Делай как в ПЛК. Есть регистры, есть объекты синхронизации на запись-чтение регистров, есть задача, обслуживающая Модбас. У задачи есть пул _запросов_, который она заполняет, читая очередь команд. Команды содержат код запроса, его параметры, состояние и уникальный идентификатор запроса. Тогда любая задача может просто добавить запрос в пул запросов, получить его идентификатор, а дальше попросить задачу-обработчик Модбаса непрерывно исполнять запрос, исполнить один, и так далее. Обрати внимание, что доступ к пространству регистров только через объекты синхронизации, поэтому, возможно, для получения минимальных задержек понадобится сделать двойную буферизацию доступа. Ещё не забывай, что каждый запрос на работу с очередью сообщений это вызов ОС, что долго/дорого, особенно с учётом копирований в/из очереди.

Зачем? Разреши приём при передаче. Сработал IDLE, значит, передача закончилась и можно переключаться на приём. Попутно проверишь, что принятое совпало с отправленным.

Для F4 это правильное решение. Красивое решение называется MAX13487.

Есть два способа. 1) Купить промышленную "мамку" с ISA. Таких мало, но они выпускаются. Гугл в помощь. 2) Купить преобразователь USB-ISA.

Разобрался с фрагментацией. Ошибка была у меня, причём на стороне сервера, работающего под Виндой. Вот описание буферов: char *inputMessage, *outputMessage; uint16 sizeOfInputMessage, sizeOfOutputMessage; Вот так получал сообщение: // Получаю данные от клиента. clientSockErr = \ recv( clientSock, inputMessage, sizeof( inputMessage ), 0 ); А вот так должен был: // Получаю данные от клиента. clientSockErr = \ recv( clientSock, inputMessage, sizeOfInputMessage, 0 ); Спасибо Ирине Ким с сайта Wiznet, котороя обратила моё внимание на то, что с сервера уходят подтверждения получения на части пакета от клиента, а не на весь пакет.

А сам пробовал пользоваться IPC при создании посадочных мест? Я попробовал в Альтиуме, так он какую-то несуразицу выдаёт, весьма далёкую от футпринтов в мурзилках производителей элементов.

Странный вопрос. Все производители компонентов указывают рекомендуемый футпринт. Для 1мм, обычно, рекомендуют 1.2мм.

GCC ld Общее описание + ссылки внизу

Если внимательно прочитать ЕСКД, то можно узнать, что разработчик вправе создать свою систему условных обозначений и использовать её. Главное- это описать её на первых страницах документа. Единственное, по-моему, это не злоупотреблять этой возможностью, то есть не переиначивать уже описанное в ГОСТ, но описывать и использовать вещи, которые или исключены из действующих стандартов, или стали удобными и привычными из-за их постоянного лицезрения в буржуйских мурзилках.

Благодарю!

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

Всё очень просто. Принимать пакеты ты будешь через recvfrom(), у которого один из параметров это как раз указатель на структуру с адресом отправителя, поэтому от кого пришло сообщение ты узнаешь без проблем. Ессно, по этому же адресу отправишь ответ. Ещё учти размеры сообщений и размер приёмного буфера у 5500. Возможно, тебе есть смысл увеличить размер буфера приёмника.

MathCAD от рождения использовал движок Maple. Несколько лет назад они то ли полностью, то ли частично от него отказались, написав свой. Maple умеет вставлять в документы таблицы из Экселя, поэтому оформление таблицы делается прямо Экселем. Странно, что в других пакетах вы этим не пользуетесь, хотя, по-идее, такое должно быть. Не знаю как сейчас, а раньше для Maple была бесплатная студенческая лицензия. Да, урезанная, но для большинства инженерных применений её хватало с избытком.

А затем, что включил в терминале семибитный режим и всё прекрасно видно, без всяких дополнительных утилит-нахлобучек как в RTU.

Завтра ещё раз посмотрю осциллографом ноги у 5500. Может, где-то чё-то осталось, что дёргает ноги у 5500, вот он и дурит. Мне тут приходится прикручивать к проекту на ХАЛ свои наработки, возможно, где-то чё-то не доглядел, глаз замылился и на, получите-распишитесь. Я же помню, что года 3 назад, когда щупал 5500, у меня сообщения нормально передавались.

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

Wireshark 1.10 Свежие версии не хотели работать, а эта легко и без вопросов завелась.

Тех контроллеров у меня уже давно нет, работают на объектах. Каркас сервера в своё время делался для работы как раз с Модбас. Был зоопарк разных контроллеров, поэтому я написал каркасы сервера и клиента. Собирал их в разных вариантах для тестов. Тогда всё сходу завелось и заработало. А тут затык, и не понятно куда рыть. А что это даст? Вроде, и так видно, что 5500 пилит сообщение и повторяет отправку, хотя его никто явно не просит это делать.