Тач контроллер - это обычно отдельная микросхема в составе дисплея. Что-то типа FT5336. Проще посмотреть код, который ST предлагает использовать с этой платой.
Сторонняя "умная" реализация fifo здесь действительно не нужна - звуковой семпл это не какая-то сложная структура, добавляются семплы с известной периодичностью, как и читаются. Фифо у вас уже есть, и декью при этом - просто чтение данных по указателю на начало или половину буфера + n семплов назад. Реально сдвигать очередь не нужно - запись всегда идёт в другую половину.
Как только вы попробуете крутить хоть сколько-нибудь сложное DSP, это станет очевидно по быстродействию.
Это для ИИ задача посложнее уже. Как же разочаровывает этот прекрасный новый мир, где README.md сгенерирован машиной и набит смайликами, а чтобы добавить фичу, "программист" пишет "calude, add the feature as described, make no mistakes", и потом нам заявляет "я написал". Ну да, промт написал.
Производители любых авто просто так никому свои dbc не выдают. Более того - существующие CAN протоколы передаются от разработчика одной системы автомобиля разработчику другой за колоссальные деньги. То что Яндекс не смог или не захотел купить описание сообщений у производителя - это проблемы Яндекса, а не всея Руси.
Всё что вы перечисляете не является требованием к наличию энергонезависимой памяти. ManufacturerSpecific величины могут не быть реализованы. DTC не обязательно сохраняются в ЭНП. Сервис для записи данных может быть не реализован.
Что такое семплы модуляции?
Вас ведь не заставляют петь на работе?
"Эти программисты не могут спеть даже простейшую песню"
Тач контроллер - это обычно отдельная микросхема в составе дисплея. Что-то типа FT5336. Проще посмотреть код, который ST предлагает использовать с этой платой.
Этот ASIC - это дисплей.
А есть какой-то эталон крепости чая, который надо соблюдать?
В слитых исходниках на картинке также изображен блок управления ГБО. Его можно было не обрезать.
Как при частоте fs = 48 кгц вы получили LRCLK 53.591 кГц?
Сторонняя "умная" реализация fifo здесь действительно не нужна - звуковой семпл это не какая-то сложная структура, добавляются семплы с известной периодичностью, как и читаются. Фифо у вас уже есть, и декью при этом - просто чтение данных по указателю на начало или половину буфера + n семплов назад. Реально сдвигать очередь не нужно - запись всегда идёт в другую половину.
Как только вы попробуете крутить хоть сколько-нибудь сложное DSP, это станет очевидно по быстродействию.
Это для ИИ задача посложнее уже.
Как же разочаровывает этот прекрасный новый мир, где README.md сгенерирован машиной и набит смайликами, а чтобы добавить фичу, "программист" пишет "calude, add the feature as described, make no mistakes", и потом нам заявляет "я написал". Ну да, промт написал.
О каких топовых компаниях идёт речь?
Это RTFM, здесь отладка никак не поможет
Производители любых авто просто так никому свои dbc не выдают. Более того - существующие CAN протоколы передаются от разработчика одной системы автомобиля разработчику другой за колоссальные деньги.
То что Яндекс не смог или не захотел купить описание сообщений у производителя - это проблемы Яндекса, а не всея Руси.
Вы же сам пишете, что находитесь в начале пути. Откуда вам знать, как не убить здоровье, если это заметно только со временем?
Приведите, пожалуйста, пару примеров разработанных вами программных продуктов или их составных частей.
Всё что вы перечисляете не является требованием к наличию энергонезависимой памяти. ManufacturerSpecific величины могут не быть реализованы. DTC не обязательно сохраняются в ЭНП. Сервис для записи данных может быть не реализован.
Описание UDS сервиса не является требованием к аппаратной части ЭБУ. Если эти сервисы не реализованы, ничего нигде не надо хранить.
В каком пункте стандарта явно говорится о требовании иметь энергонезависимую память?
Вывод простой - чувствительность вашей мыши недостаточна, раз это заняло две недели