xvr

Он проиграл SPARC'у, который разрабатывали теже самые инжинеры и компилятор писали теже самые програмисты. Так что увы, мимо кассы OOO тогда ещё не появилось. а когда оно появилось Моторола И Alpha уже почили в бозе. Sparc немного потрепыхался, и даже OOO успел себе привить, но увы, не выплыл. В x86 аппаратный стек (на push/pop) почти не используется - во первых сами команды push/pop не эффективны, а во вторых как раз из за OOO. Компиляторы используют регистр sp для отслеживания позиции в стеке, а обращение туда делается командами mov по sp+смещение. Если не верите - посмотрите ассемблерные листинги от компилятора. push может быть останется при вызове функции, но и то не факт. Т.е. стек приводит к замедлению, я правильно понял? А это следут понимать как 'не выпендривайтесь, и пишите сразу на С', я правильно понял? В PicoJAVA были попытки исправить ситуацию. SUN добавил в Java VM команды для прямой работы с аналогами регистров и попытались сделать JIT оптимизатор, что бы их использовать. Не помогло - компилятор не справился 😞 Так что изначально неэффективное аппаратное решение никакие компиляторы не вытянут 😞 Я ничего не имею против Forth, как языка. Но не надо пытаться представить его как панацею, которую зажимают производители CPU, что бы протолкнуть свою архитектуру. Восторженные статьи на тему 'наш Форт порвал 386 процессор как тузик грелку - давайте массово делать Форт процессоры, пока Intel не опомнился' у мало мальски осведомлённых в архитекрурах CPU инжинерах вызывает только гомерический хохот. Forth хорошь в микроконтролерах, но и там у него есть проблемы - он оказывается слишком сложным, как это не странно. Стек это аппаратура, построенная поверх регистров, и без неё можно обойтись. По поводу статей, мне особенно запомнился один перл (от какого то нашего Forth процессора) - 'у нас настолько быстрый процессор и такая компактная кодировка, что нам кэши не нужны'. Соственно после этого пассажа очень сложно воспринимать всё остальное всерьёз 😞

Бред. Был комерческий стековый процессор - PicoJAVA. Провалился с треском и был отправлен в public domain. Стековая архитектура хорошо подходит для викроконтролеров и подобных. Для высокопроизводительных процессоров она не подходит - на неё не ложится OOO. Все команды оказываются зависимыми (через стек), и никакого распараллеливания на уровне комманд не происходит.

А как схема должна запускаться? При старте нет обоих напряжений, по вашему ТЗ всё должно быть выключено (видимо навечно).

В любом случае вы сможете записать только то, что ваша программа на Qt передала/приняла. Вы не сможете запротоколировать то, что физически происходит на пинах порта. Так и пишите в файл сразу из Qt. Запись в файл вещь довольно быстрая (для ваших объёмов), так что для неё не нужны отдельные thread'ы Так задействуйте и запись в файл там же.

На дом повесить коробку побольше (что бы была хорошо видна отовсюду), из неё должен торчать проблесковый маячёк. Всё, собственно сигнализация не нужна 🙂

Запись чего и куда? Зачем отдельный thread? У вас гигабайты информации собираются записываться? Или отправка записывыемых данных планируется голубиной почтой?

В Linux драйвере этого чуда Тайваньской инжинерной мысли есть такие строки: if ((cflag & CSIZE) == CS7) { data_bits = 7; } else if ((cflag & CSIZE) == CS5) { /* Enabling 5-bit mode is really 9-bit mode! */ data_bits = 9; } else { data_bits = 8; } portdata->trans9 = (data_bits == 9); Попробуйте включить 5 битовый режим, вдруг повезёт 🙂

Знак проверяется правильно, а вот сдвиг частичного остатка (п3 в вашем алгоритме) делается не правильно. Ну и собственно реализация в целом неправильная - у вас описан алгоритм, а не схема. HDL язык - это не язык програмирования! Это язык описания аппаратуры. Посмотрите какие нибудь примеры, как на нём пишут.

Да, про сенмент я как то не подумал. Значит надо 2 строки добавить - сегмент + данные

Для начала отделите инициализацию cnt, divider_copy, remains и reg_quotient от их дальнейшего вычисления. Сейчас у вас на каждом такте вычисляется одно и тоже Для определения что числа поступили используется отдельный сигнал, а не проверка данных на X - эта конструкция синтезируется не так, как вы ожидаете 🙂

Вот это как раз просто сделать (для iHex) - он содержит адрес в каждой строке. Так что просто убираете последнюю стоку (там служебная информация), дописываете строку с вашими данными с адресом FFFF8 и дописываете обратно ранее убранную последнюю строку.

Судя по диаграммам из датчиков читается нечто небольшое и переменное (+/- 0). А что вы из них ожидаете? PS. В DS написано: Т.е. это числа со знаком, а не unsigned, как трактуются в Adafruit классе. Похоже бага в Adafruit_LIS2MDL

Не они сами, а то, что за ними включено - ваши LIS2MDL. Ведь TCA9548A это не мосты I2C, а просто ключи. Все каналы, что были включены, напрямую подключаются к I2C мастера, а не обрабатываются самой TCA9548A, т.е. если вы в дальнейшем не образаетесь к TCA9548A её каналы всё равно остаются подключёнными к I2C.

У вас сейчас одна TCA9548A установленна, или все 3? Не могут они подраться -у каждой свои коммутируемые каналы, но между собой они не переключаются. Кстати у вас в коде нет отключения каналов TCA9548A при переключении на следующий коммутатор. PS. Можете попробовать (для отделения мух от котлет) запустить вашу таску без FreeRTOS - временно уберите отуда операции с семаформаи и замените xTaskDelay на Arduino delay. И позовите её прямо из start(). Если заработает, то нужно искать в FreeRTOS примитивах (что маловероятно). Если нет - то разбираться с I2C коммутаторами и пр.

Тогда объясните, почему именно так. Строки у вас так передаваться не будут - только их адреса, которые всегда одинаковые. Если у вас из очереди данные читаются и обрабатываются всегда быстро (так, что исходный массив не успевает затереться), то работать будет. Но тогда и очередь особенно не нужна 🙂

Эвучит как бред. А это звучит как жалоба человека не знающего С на то, что компилятор работает так, как положено по стандарту, а не так, как ему хотелось бы. Можно поподробнее про 'потерю стека навсегда'? Если под этим имеется в виду, что компилятор не переиспользует место в стеке для переменных, назодящихся в разных непересекающихся скопах, то он имеет право так делать. Возможно поднятие уровня оптимизации более -O0 поможет. XC8 тоже возможно поможет. Подозреваю, что вы неправильно используете очередь. Очень странно засовывать в неё одни и теже значения (у вас адресов указателей всего 2 штуки)

Ну почему же - Analog Devices ADUC серия

Вопрос не в колическтвае тасков, а в сочетании ОДНОГО инстанса класса Adafruit_LIS2MDL, который у вас обслуживает НЕСКОЛЬКО физических датчиков. Вы уверены, что он на это расчитан? И со стороны аппаратуры - в шилде LIS2MDL (или у каждой микросхемы, если они у вас в виде микросхем) есть своя поддяжка I2C? Так как при переключении каналов TCA9548 у вас только один канал будет подключён с I2C шине (с её поддяжкой), а остальные останутся без подтяжек на их конце I2C вообще - неизвестно как они на это отреагируют.

Так, придётся прокачивать телепатические способности. Кому то нужно написать прошивку для какого то ARM микропроцессора (в IAR Workbench) Эта прошивка должна содержать в себе какой то алгоритм обработки сигнала и сам сигнал (который исходно задаётся в виде wav файла). Куда должен попасть результат обработки - покрыто мраком. Так? Вопрос - как передать этот wav файл алгоритму в МК, так?

Посмотрел, должно работать. А вот к коммутации датчиков есть вопросы - у вас 1 инстанс для опроса датчика, и 20 штук разных датчиков. Могут не сочетаться 😞

И что они с ним должны делать в IAR? IAR же не медиаплэйер 🙂

Пардон, это вопрос не вам а ТС.

разные точки входа. У Arduino это setup() и loop(), у FreeRTOS это любая процедура, которая зовётся из стартапа и заканчивается vTaskStartScheduler() Например в isp-idf это библиотечные функции esp_startup_start_app и esp_startup_start_app_other_cores, а пользовательский main это app_main() Как у вас скрещивали Arduino и FreeRTOS не понятно.

А как вы Arduino с FreeRTOS скрещивали? Родная FreeRTOS не понимает ни start() ни loop() функций.

Это общая проблема любых алокаторов памяти. К связке FreeRTOS и RapidJSON она отношения не имеет.