Согласиться с вами не можем. Но надо сказать, что первоначально был выбран крокодил. Однако с его анимацией возникли трудности из-за сложной геометрии головы — у нас в приложении можно покупать, например, разные шапки для персонажа. Поэтому в итоге выбрали все-таки белку.
Расхождение данных, записанных в системе, в сравнении с реальностью — это, конечно, может случиться. Тут нужно понимать, что задача приложения — помочь больному, а не принудить его к лечению через силу. Любую систему контроля при желании можно обмануть, но мы исходим из идеи, что больной хочет поправиться, так ведь? Кроме того, полной самостоятельности от ребенка не ожидается — для этого (в том числе) и сделано родительское приложение. Есть также технологические решения проблемы — например, можно было бы интегрироваться устройствами, выдающими пилюли по расписанию, и программно определять, что нужная таблетка съедена. Но действительно ли это требуется (тем более от концепта) — большой вопрос.
В клинических исследованиях ePRO (electronic patient-reported outcome) система — только вершина айсберга. Личные наблюдения пациента объединяются с записями врача о ходе лечения и результатами анализов. Каждый врач ведет несколько пациентов, причем для чистоты эксперимента не знает, какой именно препарат принимает больной (чаще всего новые лекарства сравниваются с аналогами, а при нетяжелых заболеваниях иногда используется плацебо). Затем информация по всем пациентам анонимизируется и передается в команду, ответственную за проведение исследования. Таким образом, становится возможным делать статистически значимые выводы о том, как именно тот или иной препарат влияет на ход лечения. Разумеется, на данной стадии развития у нашего приложения бекэнда как такового нет, но мы сможем его построить при необходимости.
Да, получить аудио обратно уже не получится. Но база данных поставляется в двух видах: tfrecord и csv. Во втором файле хранятся ссылки на оригинальные видео с Youtube и временные интервалы на этом видео, когда был звук. Т. е. его можно найти и послушать.
Здравствуйте! Спасибо за комментарий, критику принимаем. Мы пока не делали поддержку мобильных платформ. Для ответа на многие вопросы надо читать код, а делать это на мобильнике нелегко. Недаром IDE для iOS и Android — это экзотика. Мы тем не менее думаем, как лучше адаптировать игру для маленьких экранах — задача стоит в очереди.
С драйверами и стабильностью дела обстоят очень хорошо, ни разу не было нареканий. А вот со стороны документации и комьюнити дела уже похуже: если потребуется сделать что-то серьезное и/или завязанное на железо, просто нагуглить решение не получится. Raspberry Pi в этом плане, конечно, вне конкуренции.
Для обеих плат тесты были проведены в 1 поток. Если взгляните на исходные коды теста — то увидите, что там явно используются 64-битные числа. Арифмитические операции 64-битных чисел на 32-битных регистрах может занимать в несколько раз больше тактов, чем арифметика с числами с разрядностью процессора. Было бы у RPI3 ядро, использующее процессор в 64-битном режиме, такой разницы не было бы. Но, к сожалению, официальное ядро, видимо, из-за соместимости с RPI2, делают 32-битным. Так что в этом тесте все закономерно.
DMA все тем же одним каналом (внутри контрольных блоков адрес назначения меняется на адрес PWM-модуля) пишет в FIFO буфер модуля PWM. Дело в том, что PWM-модуль сериализует свой FIFO-буфер с жесткой ограниченной частотой, и DMA-модуль при копировании данных вынужден ждать сигнала готовности принятия данных в буфер. Получается, что мы можем реализовать довольно точную задержку за счет того, что запись N байт в PWM займет известное (согласно частоте PWM-модуля) время.
Первый блок выставляет высокий уровень, затем второй блок задает задержку, сколько держать высокий уровень, после этого третий блок устанавливает низкий уровень, а четвертый, что эта задержка до начала следующего импульса. Итого четыре блока.
P. S. Спасибо за вопрос, удаление, разумеется, не было преднамеренным!
mlock() блокирует лишь виртуальную память, т. е. он предотвратит попадание памяти в swap. Но реальный адрес в физической памяти все равно может быть изменен, т. к. память может быть перенесена по желанию менеджера памяти (например, чтобы дефрагментировать память).
В документации ядра сказано: Linux supports migration of mlocked pages and other unevictable pages. This involves simply moving the PG_mlocked and PG_unevictable states from the old page to the new page.
Жаль, только в 1 МБ оперативной памяти STM32H7 создать буфер для длительной работы DMA не получится. Да в принципе DMA здесь будет оверкиллом, эффективнее в рилтайме считать и дергать выводы напрямую из регистров.
Но в любом случае я сомневаюсь, что вы сильно забьете шины этими активностями. Гораздо раньше вы упретесь в производительность вычисления какого-нибудь синуса или косинуса при реализации круговой интерполяции… Даже 4х ядер Raspberry Pi при вычислении тригонометрии заданного движения вряд ли хватит чтобы существенно занять полосу DMA.
P. S. Спасибо за вопрос, удаление, разумеется, не было преднамеренным!
В документации ядра сказано: Linux supports migration of mlocked pages and other unevictable pages. This involves simply moving the PG_mlocked and PG_unevictable states from the old page to the new page.
Но в любом случае я сомневаюсь, что вы сильно забьете шины этими активностями. Гораздо раньше вы упретесь в производительность вычисления какого-нибудь синуса или косинуса при реализации круговой интерполяции… Даже 4х ядер Raspberry Pi при вычислении тригонометрии заданного движения вряд ли хватит чтобы существенно занять полосу DMA.