juvf

"После написания программ на прикладном уровне, от программирования на уровне ядра/периферии мозг пухнет". Ардуино - это прикладной уровень. Все низкоуровневые "драйвера" написаны и оформлены в некий фреймворк (в классы). В STM32 "Укажи ногу - Настрой ногу - Включи АЦП - Настрой регистры - Прочитай АЦП - выключи АЦП" - это драйвер. В Атмеле (который уже давно микрочип) всё тоже самое, если не использовать готовые либы.

Ого.... вы посмотрите демки на TouchGFX ( раз, два, ....) Это не примитивный пиксельный вывод текста. Сколько человекочасов нужно на подобный движок? Вы ещё скажите "мне проще самому замутить GUI-движек, чем использовать Qt".

"слышу звон, да не знаю где он". Не путайте тёплое с мягким. CubeMX не может ни чего компилировать. CubeMX может только генерировать исходный код. Компилирует в CubeIDE по дефолту gcc. CubeIDE - это всего лишь IDE редактор кода с плюшками. В нём можно не использовать плюшку CubeMx, можно не использовать HAL.

2gretis - что-то треш какой-то. У меня на 3-х ПК нет таких катастроф. Вангую, что у вас проблемы CubeIDE связанны с вашим "окружением". Какая ОС? Какой ПК? Жава? У меня на win10-64 с фуфыкс6100 ни каких подобных проблем не возникало. эклипс работает на жаве и просит её присутствия. у меня до установки cubeIde уже была жава. Подскажите, дистрибутив cubeIde содержит в себе все что ему нужно, или нужно потом что-то доустанавливать отдельно?

букварь для встраиваемых линуксов "Embedded Linux System Design and Developent" ( перевод ) по сетям "Сетевое программирование от Бриджа" Сетевое программирование от Бриджа.pdf

Ни разу не встречал ни одного упоминания (книги/web) где бы давалось практическое или теоретическое руководство по написанию драйвера для linux (для любого ПК, в том числе и RP) на языке Phyton. Везде СИ. Можно пруфлинк на такие книги, плиз. Драйвер - это ПО взаимодействия с GPIO на уровне ядра/перефирии(МК/CPU), а управление светодиодом через GPIO - это скорее всего прикладная программа, а не драйвер. Прикладное ПО пишут на чем угодно, питон/с/ява.... а вот драйвер - всё таки си. Wiring PI в помощь

да, своими наездами, таких как этот я вас лично чем-то обидел?

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

в смысле? что мешает поменять схему двойной амплитуды на схему одинарной? не знаю . Что ТС-у мешает использовать вместо подъемного крана автобус биппер так, чтобы он звучал гораздо тише?

вы не видите, что у ТС другой режим работы бипера? У ТС схема с двойным "размахом амплитуды"

а что мешает сделать новый проект в STM32Cube IDE и закинуть в него свои исходники из старого проекта?

наверно ни как. это может делать делает gcc. Заставь эклипс вызывать gcc. Добавь в настройки сборки в eclipse cubeIde (Properties->C/C++ BUild->Settings-Build Steps->Post-build steps) arm-none-eabi-objcopy.exe -O ihex myProg.elf myProg.hex ps пока писал, alex770 дал более простой ответ.

пффф..... понятно что стресс-тест может выявить всё что угодно. в стресс-тесте может SPI лечь ртос лечь, может обмен лечь, может ПО или железо (как и сам проц, так внешнее от процессора).... Всё что вы говорите - относиться ко всему изделию, включая как железо, так и софт. Что конкретно вы можете сказать про аппаратный i2c в stm32? Вы делали стресс-тесты и вылетал i2c? Или через 1...6 месяцов в серийных изделиях в реальной работе аппаратный i2c ложился?

это и есть 2). спс

ну это понятно.... с помощью мьютексов можно сделать и 1) и 2). Просто не хотел заморачиваться. Думал может вызов printf() помещает в поток текст единым куском, и параллельный вызов printf() "не порвёт" строку из др потока. ps кстати..... printf() что делает.... открывает поток stdout , помещает текст, закрывает поток.... если в первом таске открыли stdout, то во втором таске printf() не заблокируется на открытии stdout?

я хочу из разных потоков выводить дебажную в терминал. в одном потоке printf("string 1\n"); printf("string 2\n"); printf("string 3\n"); в другом потоке printf("text 1\n"); printf("text 2\n"); printf("text 3\n"); 1) я хочу чтобы прога не легла при одновременном вызове std::cout или printf() с разных потоков. 2) я хочу видеть в терминале вывод с обоих потоков.... как минимум построчно разделённые, что-то типа string 1 string 2 text 1 text 2 text 3 string 3

спасибо

std::cout и/или printf() - потокозащищённые (в Linux)?

Я проглядел наверно.... ТС где-то сказал, что он собирается НЕЗАКОННО производить? Или ТС сказал, что это специальное технической средство для не негласного получения информации? И какое отношение к ТС имеет УК РФ? Он свои деяния собирается делать на территории РФ? Какое гражданство у ТС? .... у некоторых людей бурная фантазия. 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 уже удалена. Обращение к удаленному объекту!!!