juvf

Я проглядел наверно.... ТС где-то сказал, что он собирается НЕЗАКОННО производить? Или ТС сказал, что это специальное технической средство для не негласного получения информации? И какое отношение к ТС имеет УК РФ? Он свои деяния собирается делать на территории РФ? Какое гражданство у ТС? .... у некоторых людей бурная фантазия. 2ТС - раз вы не электронщик - бросайте это дело. Согласовать антенну - это ещё та задача. Теоретически вам подсказали... практически - проще/дешевле купить на али. ps про бурную фантазию.... оффтопа немного.... племяннице задали задачку: "Ёжик по лесу пошел - два гриба нашел. Лиса по лесу пошла - что она нашла?" Это не прикол, а реальная задачка для проверки детей. И есть на неё решение. Я думаю, что эта задача №1 в практике/учебе любого инженера/программиста.

1) что может быть не так? 2) почему предварительно?

всем спасибо. поднял и2ц из куба. с полпинка не взлетело. Бытует мнение, что аппаратный и2ц кривой. Вот и решил выяснить, прежде чем ковыряться в нем. и2ц на ф103 заработал со второго полпинка. Не вставал флаг передачи адреса после первого байта (адрес+r/w). Разобрался. Смутила ещё осциллограмма передачи первого байта. Какие-то фронты данных почти одновременно с фронтами клока.... да и длительность "1" разная..... Но слейв вроде стабильно отвечает. На картинке передача start + 0xA0 + ASK

Подскажите, на 2019 год аппаратный i2c в stm32f* годный?

Где тут прорыв? Ребята поднатужилось просто сделали общий установщик (атолик с плугом куба). 100 лет как уж пользую еклипс+плуги(арм, иар, куб). Раньше пользовал еклипс и отдельно куб. Появился плуг куба в эклипсе - незамедлительно поставил плуг...... но вот работать в кубе под эклипсом не совсем оказалось удобно. Стал обратно пользовать внешний куб. ИМХО.

Я не знаю зачем. Я не предлагаю вам вешать остальные потоки. Я вам говорю, что если вы вынесете LCD/I2c в другой поток и сделаете реализацию как у haker_fox, то эффекта не получите. О чем вам haker_fox написал - "Другие в это время, да, курят бамбук". Если вы сделаете как у haker_fox, то при вызове MeasCore::sendMsg(), у вас MAIN залипнет.

Про рудимент понятно..... но всётаки наверно очередь из указателей - опасно. В вашем коде заряженный пистолет ждёт чью-то ногу. возможно в вашем коде пистолет ни когда не стрельнет, но в другом коде может быть очень больно. допустим вы в майне на стеке создали структуру Msg _msg, передали ссылку в sendMsg(_msg, 100), которая передает указатель в очередь qResult = xQueueSend(m_daqMsgRxQueue, &_msg, 0); Допустим в ОС крутится много задач очень важные задачи (с приоритетом выше LCD), которые заняли МК например на 200 миллисекунд. MeasCore::sendMsg() не дождался ответа и вернул false. MAIN удалил _msg (или вышел из области _msg). Тут вдруг LCD дождался таки процессорного внимания и начал работу. Поток LCD видит в извлекает из очереди команд указатель на _msg и.... упс.... а _msg уже удалена. Обращение к удаленному объекту!!!

2topor_topor LCD драйвер реализует программный I2C. Соответственно если он идёт в MAIN то забивает надолго любую другую активность. А в отдельном потоке он работает паралельно и не видимо. Вы читайте полностью пост. Так а зачем тогда вообще очереди и драйвер выводить в отдельный поток? Вам же пишет haker_fox - " Другие в это время, да, курят бамбук", а вам нужно "работает паралельно и не видимо". Вы уже определитесь - вам шашечки или ехать? Вот я и спрашиваю, если писать код, что другие в это время курят бамбук - то зачем тогда вообще LCD в другой поток и очереди, если всё равно при таком решении MAIN забивает надолго любую другую активность?

Так а зачем тогда вообще очереди и драйвер выводить в отдельный поток? Из любого потока вызывай драйвер LCD::ReadID() и жди ответа. На вскидку: TRetVal MeasCore::sendMsg( Msg &request, Msg &replay, TickType_t _tout )

как вариант вторая очередь будет работать. Если ответов мало.... тасков мало.... вполне рабочий лёгкий вариант, без оверинженеринга. НО.... вот допустим, в очереди команд у вас уже 10 команд на выполнение, в обратной очереди 5 ответов (с других тасков были запросы). Ваш текущий таск отправляет Command::ReadID, получаем следуещее состояние: в очереди команд 11 команд в очереди ответов 5 ответов как ваш таск найдет/дождется именно ваш ответ? нужно перебрать всю очередь, в объекты Command/Ответ вводить id по которому таск найдет свой ответ. А если MAIN не дождется ответа и продолжит что-то делать, после появится ответ в очереди. Но этот ответ уже ни кому не нужен. Кто его удалит из очереди ответов? Ваша MAIN должда выдать и дождаться Command::ReadID. Т.е. MAIN заблокируется на команде. Если MAIN блокируется, то зачем Command::ReadID передавать в задачу драйвера LCD? Выполните непосредственно из MAIN медленную LCD::ReadID(). LCD::ReadID() должна быть потокозащищённая (мьютекс или симафор). Ещё вариант.... (если хорошо владеете ООП, а то ногу отстрелите), то создать очередь команд из указателей на Command. В таске драйвера lcd извлекаете из очереди указатель на Command, выполняете команду, И.... если команда с ответом, то в Command помещаете ответ и выставляет в Command флаг "выполененно". Если Command безответная (типа clear), то после выполнения команды удаляете этот объект (Command) по указателю. В MAIN ждите флаг в нужной своей Command. ps Command::флаг можно оформить через фриртосовский эвент, тогда не нужно в MAIN периодически проверять флаг, а заблокироваться на ожидании евента.

Почему не подходит? См паттрен Command. Делайте очередь из Command-ов. Или, на вскидку.... структура struct Command { void (*f)(void *data); //указатель на LCD::print(void *)/rect(void*)/clear(void*) void *data; }; в очередь структуру Command. в lcd-Таске из очереди извлекать структуру и выполнять Command::f(Command::data); в методе аргумент void * приводить к нужному, например void LCD::print(void *data) { char *text = (char*)data; this->print(text); } void LCD::rect(void *data) { Rect *rect = (Rect *)data; this->drawHorizon(rect->x0, rect->x1); ... } ну как-то так... зы ну и ещё нужно быть уверенным, что память Command::data освободиться после выполнения.

Как вариант, я бы так сделал: Два варианта с 2-х и 3-х клеммными колодками. На ПП оба футпринта разместил бы по одним координатам, в правилах бы сделал исключение. Если есть более кошерный вариант, может кто подскажет, сам возьму на заметку.

По мойму тут мухи с котлетами в куче. Что значит альтернативный компонент? Есть альтернативный режим (Mode) для отображения УГО. Компонент один и тот же, а отображение на схеме альтернативное. Можно выбрать альтернативный футпринт, для компонента, но он (футпринт компонента) будет для всех вариантов один и тот же. Судя по картинке, у вас на варианте совершенно другой компонент. Соответственно у него будет свой футпринт. Вы хотите в варианте сделать другую ПП с другим футпринтом для Х5? Но варианты вроде не так работают. Рисуется общая схема, делается одна общая печатная плата для всех вариантов. Делается вариант, в котором указывается, что "транзистор VT6 не устанавливать". Но на ПП футпринт под VT6 останется. Разве можно на варианте ставить другие компоненты с другими футпринтами?

Да, вы правы. Были скрытые полигоны, рудименты. Спасибо.

AD16. Добавил полигоны земляные. Всё как обычно. 90% пинов с цепью GND не подключилось термопадами к полигону. Почему? В правилах нет каких либо указаний про "не подключать". При этом нет "нити" которая показывает что пин не подключен. На картинке одинаковые пины, но один не подключается термопадами. ps ps ps "Смотри правила" - что там смотреть и как?