misyachniy

У договору нужно техническое задание с требуемыми параметрами и методами их проверки/сдачи. Вот возмьем эту строку: "Помимо наполнения/слива, система должна быть оборудована поддержанием постоянной температуры с помощью нагревателя/термодатчика." У меня вопросы: 1) Где поддерживать температуру в исходном резервуаре или в 8-ми? Или может и там и там? 2) Какие пределы температуры и какие точности удержания? 3) Нужно измерять температуру жидкости или температуру стенки сосуда? 4) Какая мощность нагревателя?

Это требование: "Оплата предпочтительна от юридического лица", не согласуется со строком 7 дней.

Хотя бы диапазон указали. Может нужна рентгеновская оптика.

БОльшая польза, подразумевает бОльше вложений. Разработка устройства с метрологией будет на пару порядков дороже изделия. Разработка Т.З. может обойтись в 20..30% от готового прибора.

Тут нужно минимум 3, а то и 4 инженера. И не консультация, а разработка. А если это серьезная система, то еще метролог, конструктор, радиоинженер.

Техническое задание размытое, должно быть оговорено точнее "много wi-fi точек" и "других радиопомех" "приема данных с нескольких nRF24L01P на nRF52832" " работы нескольких пар nRF24L01P + nRF52832 одновременно, чтобы не мешали друг другу" ОС Windows 10 x86/x64 не система реалного времени и не может гарантировать 100мс интервалы. Такое выражение "бесперебойный прием данных" тоже не является строгим. Можно обеспечить обмен с определенной вероятностью успешного обмена. Рекомендую в начале найти специалиста по передаче данных для написания Т.З.

Укажите какие либо "коды", позволяющие идентифицировать плату. Сожет в интернете есть схема или фото. Если внутри микроконтроллер, то возможно вопрос не решаем по простому.

По моему это изобретение велосипеда. Вопросы по сертификации не озвучены. Ни чего не сказано об аккумуляторах/зарядке. Кроме того бывают ситуации когда люди дома у телевизора, а подсоединение стиральной машины на кухне отвалилось. Или стирка с ночным тарифом, пол залит на 10см., а автоматика молчит.

Я для проверки использую передачу 0x12345678 и по ней лучше видно как переставляются данные. В данном случае, отладчик подавил лидирующие нули. У меня 0xAA0000, а не 0xAA000000. P.S. Честно говоря не пойму при чем здесь кэш. У меня процессор 32 бита, все данные стуктуры 32 бита. Что нужно выравнивать?

Сеть здесь ни при чем. Создается впечатление, что отображение в отладчике и передача параметров в функцию не одно и тоже Такая передача не работает result_cmd = parser_put(short_cmd.addr, short_cmd.data); Если объявить промежуточные переменные,то работает int answer_addr, answer_data; answer_addr = short_cmd.addr; answer_data = short_cmd.data; result_cmd = parser_put(answer_addr, answer_data);

Я работаю с ISE/XPS у меня модули "тасуются" самостоятельно. Их адреса можно закрепить отдельной галочкой. Макросы не использую использую базовые адреса из файла xparameters.h

Взял за основу пример UDP обмена на плате Spartan 6. Используюя накопленный опыт, решил использовать струтуру в которой не нужно выравнивания (надеюсь ;-)) // структура короткого запроса typedef struct{ int cmd; // код команды/запроса int addr; // адрес обращения int data; // данные для записи/чтения unsigned int crc; }SHORT_CMD; Обрабатываю пакеты под отладчиком в плате. 1) Копирую нужную часть memcpy(&short_cmd, udp_packet, sizeof(SHORT_CMD)); 2) Подсчитываю контрольную суссу, она сходиться 3) По коду запроса вызываю функцию обработки В отладчике видно что поле data имеет значение 0xAA 4)Захожу в функцию Параметр data передается в функцию с перестановкой байт. addr, наверное тоже, но не видно так как он равен нулю. Настройки процессора следующие: Допустим можно попутать big/little endian. Почему компилятор корректно извлекает из структуры число, а передает его в функцию некорректно?

LCCNENSE_NO проверяется в прерывании по приему START_PROG: JMP PROG ORG 03H CALL RS_232_IN CALL CRC_KONTROL Очевидно идет сравнение кода внутри программы с получаемым по UART. Но что происходит так просто не скажешь. Может проверка типа программы: пользователя или технологическая.

По моему Мультисим для для моделирования схем из сосредоточенных компонентов. В зависимости от задачи, нужно моделировать и переходные отверстия и финишную обработку "меди" и толщину паяльной маски.

Я так глубоко не копал, но по моему ELF формат тут не подойдет. "ELF Executable and Linkable Format — формат исполнимых и компонуемых файлов" Встраивать в bootloader разборщик/компоновщик ELF формата будет накладно. Нужно двоичный файл скомпилированый для адреса в DDR памяти. Тогда bootloader просто скопирует данные в DDR и передаст управление на него. Для передачи управления используется стандартная процедура вызова функции по указателю. Сбрасывать процесор не нужно, он опять перейдет в boot. Обычно в начале образа программы храниться таблица векторов прерываний. Первый вектор, это как раз вектор по сбросу. Надеюсь "старшие" товарищи подправят если ересь написал. ;-)