Вот только сегодня писал в поддержку, спрашивал где можно почитать юридические документы по конфиденциальности использования моделей. Нигде на странице Yandex Foundation Models в консоли управления нету даже намека или ссылки. Отзвонился специалист, сказал ищите в поиске стандартный договор Яндекса на оказание услуг облака, туда типа модели тоже подразумеваются. Ну такое... Хотелось бы получить ответы на такие вопросы:
Можно ли не в API а как-то иначе задать флаг "не сохранять мои запросы"? Есть много готовых продуктов для работы по OpenAI API, для них технически проблематично добавить дополнительное поле требуемое вашим API для запрета сохранения моих данных для обучения модели.
Ведутся ли технические логи работы модели с сохранением контекста? Даже если включено "не сохранять мои запросы"?
Где физически обрабатываются данные? Можно ли закрепить регион?
Есть ли список субподрядчиков/третьих лиц, имеющих доступ к данным? Как вы уведомляете об изменениях?
Кто-то из ваших сотрудников может видеть мои запросы? Такое технически предусмотрено?
Подписываете ли вы отдельное соглашение о конфиденциальности если требуется?
Кому принадлежат права на сгенерированный код/вывод модели?
Чем отличаются ваши режимы Web/«чат в браузере» и API с точки зрения сохранения конфиденциальности?
Можете ли вы юридически достоверно подтвердить вопросы выше без отсылок к маркетинговой информации?
Я бы оставил, не исправлял. Это реально так трагично, так эмоционально выглядит, так... человечно. Иная модель начинает тупить, нет-нет да и наругаешь её (и это помогает!). А Gemini рука не поднимается обидеть, когда читаешь как она сама себя до истерики довела. Хочется обнять, погладить и пожалеть...
Дал тут модели o3 ссылку на DO-178 в интернете и кусок старого исходника. Говорю, сделай мне рыбу чтобы была как настоящая - чтобы все документы были что требует сертификатор по DAL B на DO-178. Тесты напиши, чтобы покрытие 100%, чтобы были требования к каждой строчке, низкоуровневые, высокоуровневые, планы все напиши, чтобы трассируемость во все стороны. Ну, чтобы со всеми делами и без всяких дел. Такую рыбу, к слову, нигде не скачать и не запросить - распространяется исключительно через организации продающие услуги помощи в сертификации. Такая красота получилась! Хоть понятно примерно стало что эта бюрократия из себя представляет.
Внутри каждого файла тоже прямо с виду годнота - ну как минимум каркас. Также ИИ очень хорошо консультирует по КТ-178 - раскрывает, как можно квалификацию на инструменты оформить, как старый код под КТ-178 подвести и т.п.
Потом сходил в другой ИИ (gemini) и попросил оценить этот сгенеренный комплект документов с точки зрения инспектора.
Так что ИИ уже тут.
• SAS_PWM.md — «Итоговый отчёт о выполнении ПО» (Software Accomplishment Summary). Подводит итоги для модуля PWM версии 1.2.0: перечисляет ключевые артефакты, состояние сертификационной базы и соответствие уровню DAL B (DO-178C). • SPR_PWM_Log.md — «Журнал проблем ПО» (Software Problem Report Log). Таблица зарегистрированных замечаний, статусов их устранения, ссылок на корректирующие коммиты и ответственных лиц. • ctest_log.txt — протокол запуска модульных тестов на хосте: 1 тест пройден, сбоев нет, время ~0 с. • gcovr_report.txt — агрегированный отчёт gcovr: сводная таблица по файловому охвату кода (строки/ветви), процент покрытия, список пропусков.
docs/docs_project
• Глоссарий.md — глоссарий проекта; даёт определения DO-178C, DAL, HLR/LLR и пр. • План_верификации_ПО.md — SVP (Software Verification Plan). Описывает стратегии, методы тестирования, ответственность команд и критерии выхода для уровня DAL B. • План_обеспечения_качества_ПО.md — SQAP (Software Quality Assurance Plan). Фиксирует процессы контроля качества, ролевое распределение, метрики и частоту аудитов. • План_разработки_ПО.md — SDP (Software Development Plan). Расписывает жизненный цикл, вехи, инструменты и модель конфигураций. • План_сертификации_ПО.md — PSAC (Plan for Software Aspects of Certification). Договаривается с органом сертификации о том, какие артефакты и активности требуются. • План_управления_конфигурацией_ПО.md — SCMP (Software Configuration Management Plan). Регламент управления конфигурациями, базовыми линиями и правами доступа.
docs/docs_pwm
• PWM_История_эксплуатации.md — описание накопленного опыта использования модуля PWM, обнаруженных проблем в полёте и их решений. • PWM_Неисполненный_код.md — анализ «мертвого» (неисполняемого) кода, причины появления и рекомендации по удалению или изменению. • PWM_Описание_архитектуры.md — детальное изложение архитектуры: слои, интерфейсы, диаграммы модулей и ответственность компонентов. • PWM_Тестовое_покрытие.md — матрица покрытия тестами требований; указывает, какие треб. подтверждаются какими наборами CMocka-тестов. • PWM_Трассировка_кода.md — csv-файл с построчной трассировкой: номер строки → идентификатор требования. • PWM_Требования.md — полный перечень HLR/LLR к модулю PWM с обоснованием, допустимыми допусками и ссылками на внешние нормативы. • Журнал_независимых_ревью_PWM.md — записи независимых ревью: состав комиссии, выводы, статус действий по замечаниям. • Индекс_конфигурации_PWM.md — конфигурационный индекс «Baseline Verified»: список всех файлов, контрольные суммы (SHA-256) и версии.
docs/tool_qual
• cmocka_formc.txt — Form C (Tool Accomplishment Summary) для фреймворка CMocka: объём верификации инструмента и вывод о его пригодности. • gcovr_formc.txt — аналогичный Form C для gcovr.
docs/verification
• ctest_log.txt — журнал интеграционных тестов (та же структура, но для стенда валидации). • gcovr_report.txt — отчёт покрытия после интеграционных испытаний. • hil_tz_delay.txt — отчёт аппарат-в-контуре (HIL) по требованию HLR-PWM-02: фиксирует, что выходы переходят в «низкий» уровень < 2 мкс.
docs/trace
• PWM_Трассировка_кода.csv — см. выше (включён в список docs_pwm).
Подсолнечник действительно «тянет» кадмий из почвы, и яд накапливается в семечке сильнее, чем в большинстве других культур. Это не секрет и для западных, и для российских лабораторий. healthline.com
Нормативы и реальное содержание
* Технический регламент ТР ТС 015/2011 устанавливает предельный уровень 0,20 мг/кг для семян подсолнечника (до 2018 г. было 0,10 мг/кг). Регламент действует на всей территории ЕАЭС. ura.newsspb.aif.ru
* Большие серии проверок показывают, что большинство расфасованных семечек вписываются в норму, но часто подходят к её верхней границе (0,13–0,19 мг/кг). ura.newsspb.aif.ru
* Случаи явного превышения (выше 0,20 мг/кг) фиксируются, но это единицы процентов партий. Россельхознадзор в 2024 г. насчитал 9 «кадмиевых» отклонений из ~300 тыс. анализов (0,003 %). aif.ru
* Независимые экспертизы иногда ловят образцы с 0,21–0,40 мг/кг — то есть в 1‑2 раза выше допуска. petkach.spb.ru
Итого: разговор о том, что «все российские семечки ядовитые», — преувеличение. Но продукт действительно систематически находится «на грани» гигиенического лимита.
Что получается по дозам
* Европейская EFSA оставила предельно допустимое еженедельное поступление кадмия на уровне 2,5 мкг/кг массы тела. Для взрослого 70 кг это ≈ 175 мкг/нед. или 25 мкг/сут. efsa.europa.eu
* Пачка очищенных семечек 500 г с типичным содержанием 0,10 мг/кг принесёт ~50 мкг кадмия (вдвое суточной «безопасной» дозы). Две такие пачки в день устойчиво выводят человека за пределы TWI, поэтому при регулярной «горстевой» диете кадмий действительно копится.
* Период полувыведения Cd из тканей почек 10–35 лет, кровь очищается за месяцы, волосы — лишь «летопись» последних месяцев. pmc.ncbi.nlm.nih.gov
Про подсолнечное масло -
Если коротко
Большая часть кадмия остаётся в жмыхе, а не переходит в масло. Экстракция гексаном и последующая рафинация почти не растворяют солей кадмия. В промышленности даже есть шутка: «Cd ‑ это проблема кормов, а не фритюра». На научном языке: «Cd концентрируется в шроте, в масле его очень мало» terresinovia.fr.
Поговорил с o3, говорит что карты старые, поддержка давно закончена, и для работы с ними надо старые драйвера, и не будут работать новые фишки ускорения вычислений. Придётся остаться на старых драйверах и библиотеках. А новых дешевых карт на 32Gb не делают. Вот его TL;DR
— MI50 32 GB: 90 % лотов — Radeon VII с наклейкой. Проверяйте PCI ID (0x66A1) и объём. Работает только на ROCm ≤ 6.3, скорость ~2 ток/с на Llama‑70B Q6. Брать стоит, если устроит цена ≤ 20 k ₽ и готовы прошивать/охлаждать.
— MI100 32 GB: новый «sweet‑spot». 750–850 USD, ROCm поддержка ещё жива, ~3–4 ток/с. Пассивный радиатор, но беспроблемней MI50.
— Tesla V100 32 GB PCIe: CUDA 12.x, 600–900 USD. Чуть быстрее MI100 благодаря Tensor Cores, зато памяти впритык.
— Свежих «нищебродских» 32 GB нет: W6800/W7800 стоят 1,3–2,5 k USD, RTX 5000 Ada ~4 k USD. Дешевле только древние MI/V‑серии.
— Склеить две 16 GB‑карты можно (--tensor-parallel-size 2 в vLLM), но PCIe съест выгоду: прирост < 30 %, а сложностей × 2. Без NVLink это вариант «поместить модель любой ценой», не «ускорить».
Итого: либо берём один честный 32 GB HBM (MI100 / V100) и живём спокойно, либо готовимся к танцам с двумя 16 GB и скорости уровня одной карты. Чудес дешевле пока не завезли.
Как бы ещё отслеживать включены ли у уборочной машины щетки/пылесос, касаются ли щетки того что они должны чистить и не выходит ли вся убранная пыль через верх в трубу без фильтра. Примерно половина видимых мной уборочных машин в Москве занимаются профанацией - просто медленно едут экономя топливо, а щетка или поднята, или выключена, или пылесос не сосёт и т.п. Но траектория и скорость соблюдается отменно! Нужно ставить датчики мощности на агрегаты машины, чтобы отслеживать их состояние и холостой ход. Маршруты это даже не пол дела.
Больше напрягает поза из которой разработчики на него смотрят. Это вообще что? Прикол? Попытка скрыться от камеры? Может, от роботов пахнет? Или это готовность быстро проглотить капсулу с ядом...
У меня давече с другим проектом gpt o3 имел проблемы с ориентацией по гитхабу, а zip файл он разархивировал внутри и сразу все прочитал. Да и в plus подписке ограничивается число вызовов в неделю, и там и там один - что ссылку дать, что архив. Ну да лирика все это, и так понятно.
Ну почему другой - и тот и этот написали что больше части файлов нет, а именно привязки к микроконтроллерам. Разнится оценка вклада имеющегося кода: один раз он написал что это только скелет с обертками, другой раз решил что это уже половина дела уже. Ну а так-то да, gpt что дышло, как спроси так и вышло
Ну вот, говорит, вместо использования кучи аппаратных меилбоксов, как в моём оригинальном драйвере (каждый меилбокс со своим ID и приоритетом) мне придется самому программно засовывать все сообщения в единую свою FIFO очередь и вызывать ваш can_api_transmit_data - но который может ещё и не записать данные, и надо проверять что сообщение ушло через can_wait_tx_done_ll. А оно может не уйти, потому что, скажем, линия занята низкоприоритетными сообщениями, а мне надо отправить что-то срочное. И мне придется отменять отправку текущего сообщения (которое застряло и не уходит) и проталкивать более срочное. Притом что у вас CAN_abort пока и не предусмотрено. Итого, придется работать с CAN "через одну дырку" делая программно свою приоритизированную очередь, вместо того, чтобы натолкать новых данных в десяток аппаратных мейлбоксов и забыть - сами отправятся по своим триггерам и приоритету (сейчас у меня так). В итоге накладные расходы использования вашего MCAL это не "10-20 тактов процессора" на вызов обертки MCAL, а существенное изменение архитектуры драйвера, который вместо полагания на аппаратные возможности микроконтроллера будет вынужден пользоваться кастрированным узким API MCAL, тратить кучу ресурсов на организацию своих приоритетов, FIFO и менеджера отправки данных в сеть CAN.
Да а как нынче жить-то без этого... это же как вторая голова. Вот пока это пишу, оно мне рассказывает как с помощью Вашего MCAL выглядел бы мой драйвер J1939. Но вообще надо клод брать, вчера вот 4й вышел.
Ну мой o3 - я ему дал весь репозиторий в zip - говорит что всё настоящее, но только верхний слой абстракции, без слоёв микроконтроллеров. И частично рукописное. Цитирую o3:
В папке mcal_common/ лежит ≈ 30 модулей (GPIO, UART, DMA, …). Для каждого «живого» модуля присутствуют:
_general.c — основная логика (state-машины, буферы, таймауты и т.п.);
*_commands.c — набор CLI-команд для отладочной консоли;
*_diag.c — обход регистров, self-test, счётчики ошибок. Код этой части компилируемый и читабельный — он написан вручную (комментарии, осмыслённые имена, нет признаков автосгенерированного мусора).
Общие макросы COMPONENT_GET_NODE/CONFIG и ссылки на code_generator.h показывают, что к каждой сборке должен добавляться автоматически сгенерированный файл с описанием таблиц конфигурации (маску выводов, частоты, номера каналов…). Сам генератор (скрипт/утилита) в архив не положен.
MCU-специфичного слоя нет вообще. Нет каталогов вида mcal_stm32f4/, mcal_esp32/ и даже простых «заглушек» с прямым доступом к периферии. Поэтому все вызовы вида gpio_pin_set_ll(), adc_start_ll() и т.п. остаются «висящими».
Отдельные модули действительно пока пустые: например, mcal_common/wdg/ содержит только wdg_const.h и .mk — чистый каркас без строчки кода.
Чем уже можно пользоваться
Алгоритмическая «верхушка». Логика обмена по CAN (очереди, сортировка по приоритету, ожидание TX Ack), I²C-FSM, FSM для I²S full-duplex, универсальные таймерные обёртки, фоновые state-машины PWM/RTC — их можно подключить к своему проекту и «подшить» к собственным низкоуровневым вызовам.
CLI-команды и диагностика. Если заведёте свою систему логов (log.h) и консоль, уже готов базовый набор команд: adc_init, gpio_toggle, dma_stat, …
Make/CMake-инфраструктура. Файлы mcal.mk и mcal.cmake умеют по флагам подключать нужные модули, размазывать #define HAS_<MODULE> и добавлять include-пути.
Что придётся дописать
Нижний уровень для каждого семейства МК. Создаёте папку mcal_<chip> и реализуете функции *_ll() (low level), структуру ComponentDriver_t, ISR, карту прерываний. Это 70-80 % работы.
Генератор конфигурации. Скрипт (часто на Python) читает YAML/Excel со схемой платы и штампует code_generator.h + *_config.c. Без него даже общая часть не соберётся: массивы AdcNode[], GpioPad[], ClockDomain[] просто не объявлены.
Сторонние заголовки. Упоминаются, но отсутствуют: convert.h, time_mcal.h, none_blocking_pause.h и др. Их нужно либо написать, либо убрать зависимости.
Сгенерировано или вручную?
Файлы .c / .h внутри mcal_common — рукописные. Есть авторские комментарии, LOG_INFO() расставлены выборочно, стилистика единообразна.
Автоген требуются только для структур данных (константные таблицы и массивы), на что прямо указывают закомментированные строки #include "c_defines_generated.h".
Итого
Репозиторий даёт полноценный «бизнес-слой» периферии (state-машины, очереди, CLI, диагностика).
Без собственных драйверов и конфигуратора он нерабочий — это половина конструкции.
Писать придётся много: низкоуровневые функции для каждой периферии, генератор таблиц и пару вспомогательных утилит.
Читал-читал и думал - ну вот сейчас автор покажет реализацию своего MCAL на гитхабе, ну или хотя бы примеры, как может быть красиво и абстрактно реализован тот же доступ к GPIO при таком зоопарке подходов. Не говоря уже о каком-нибудь CAN - там даже философия аппаратных модулей внутри микроконтроллеров разная, у кого-то есть куча ящиков, у кого-то fifo сложные и фильтры, у кого-то свой CAN-подпроцессор со своим набором команд.
Не понимаю, как можно тут придумать что-то универсальное и гибкое не получив спагетти-код или не получив ограничение функционала, где через MCAL пролезет 5% от того что умеет аппаратная часть микроконтроллера. Думал, может хоть этот момент автор рассмотрит на каком-то сложном примере, но нет... О чём тогда статья, непонятно. Я как считал что сферический в вакууме MCAL не реализуем, так и считаю.
Ну а что делать, если я хочу LLM для работы с документами организации, которые нельзя направо и налево в API LLM разбрасывать? Мне бы просто загрузить в контекст модели pdf и вопросы позадавать по нему хотя бы. Пусть хоть медленно, но хоть что-то. Так-то да, через openrouter вообще куча моделей доступна как free, в том числе даже deepseek-chat-v3-0324:free. Но провайдеры моделей же все чёрным-по-белому пишут, что собирают пользовательские промпты. На том и живут. А для дома... ну это как хобби проект, чтобы применить знания работы с локальными LLM потом где-то ещё.
У меня Qwen3-30B-A3B-Q6_K под llama запустилась на домашнем компе с видюхой в гигабайт и оперативкой 32. Генерит быстрее чем я читаю! И вроде годноту генерит, ну по крайней мере не хуже gpt 3.5 на глаз
Вот только сегодня писал в поддержку, спрашивал где можно почитать юридические документы по конфиденциальности использования моделей. Нигде на странице Yandex Foundation Models в консоли управления нету даже намека или ссылки. Отзвонился специалист, сказал ищите в поиске стандартный договор Яндекса на оказание услуг облака, туда типа модели тоже подразумеваются. Ну такое... Хотелось бы получить ответы на такие вопросы:
Можно ли не в API а как-то иначе задать флаг "не сохранять мои запросы"? Есть много готовых продуктов для работы по OpenAI API, для них технически проблематично добавить дополнительное поле требуемое вашим API для запрета сохранения моих данных для обучения модели.
Ведутся ли технические логи работы модели с сохранением контекста? Даже если включено "не сохранять мои запросы"?
Где физически обрабатываются данные? Можно ли закрепить регион?
Есть ли список субподрядчиков/третьих лиц, имеющих доступ к данным? Как вы уведомляете об изменениях?
Кто-то из ваших сотрудников может видеть мои запросы? Такое технически предусмотрено?
Подписываете ли вы отдельное соглашение о конфиденциальности если требуется?
Кому принадлежат права на сгенерированный код/вывод модели?
Чем отличаются ваши режимы Web/«чат в браузере» и API с точки зрения сохранения конфиденциальности?
Можете ли вы юридически достоверно подтвердить вопросы выше без отсылок к маркетинговой информации?
Я бы оставил, не исправлял. Это реально так трагично, так эмоционально выглядит, так... человечно. Иная модель начинает тупить, нет-нет да и наругаешь её (и это помогает!). А Gemini рука не поднимается обидеть, когда читаешь как она сама себя до истерики довела. Хочется обнять, погладить и пожалеть...
Тем временем на али-экспресс: "Бесщеточная 8-дюймовая электрическая бензопила, автоматическая масленка для обрезки цепной пилы, ручная садовая обрезная бензопила, деревообрабатывающий инструмент для Makita, аккумуляторный штифт 18 В"
Дал тут модели o3 ссылку на DO-178 в интернете и кусок старого исходника. Говорю, сделай мне рыбу чтобы была как настоящая - чтобы все документы были что требует сертификатор по DAL B на DO-178. Тесты напиши, чтобы покрытие 100%, чтобы были требования к каждой строчке, низкоуровневые, высокоуровневые, планы все напиши, чтобы трассируемость во все стороны. Ну, чтобы со всеми делами и без всяких дел. Такую рыбу, к слову, нигде не скачать и не запросить - распространяется исключительно через организации продающие услуги помощи в сертификации. Такая красота получилась! Хоть понятно примерно стало что эта бюрократия из себя представляет.
Внутри каждого файла тоже прямо с виду годнота - ну как минимум каркас. Также ИИ очень хорошо консультирует по КТ-178 - раскрывает, как можно квалификацию на инструменты оформить, как старый код под КТ-178 подвести и т.п.
Потом сходил в другой ИИ (gemini) и попросил оценить этот сгенеренный комплект документов с точки зрения инспектора.
Так что ИИ уже тут.
• SAS_PWM.md — «Итоговый отчёт о выполнении ПО» (Software Accomplishment Summary). Подводит итоги для модуля PWM версии 1.2.0: перечисляет ключевые артефакты, состояние сертификационной базы и соответствие уровню DAL B (DO-178C).• SPR_PWM_Log.md — «Журнал проблем ПО» (Software Problem Report Log). Таблица зарегистрированных замечаний, статусов их устранения, ссылок на корректирующие коммиты и ответственных лиц.
• ctest_log.txt — протокол запуска модульных тестов на хосте: 1 тест пройден, сбоев нет, время ~0 с.
• gcovr_report.txt — агрегированный отчёт gcovr: сводная таблица по файловому охвату кода (строки/ветви), процент покрытия, список пропусков.
docs/docs_project• Глоссарий.md — глоссарий проекта; даёт определения DO-178C, DAL, HLR/LLR и пр.• План_верификации_ПО.md — SVP (Software Verification Plan). Описывает стратегии, методы тестирования, ответственность команд и критерии выхода для уровня DAL B.
• План_обеспечения_качества_ПО.md — SQAP (Software Quality Assurance Plan). Фиксирует процессы контроля качества, ролевое распределение, метрики и частоту аудитов.
• План_разработки_ПО.md — SDP (Software Development Plan). Расписывает жизненный цикл, вехи, инструменты и модель конфигураций.
• План_сертификации_ПО.md — PSAC (Plan for Software Aspects of Certification). Договаривается с органом сертификации о том, какие артефакты и активности требуются.
• План_управления_конфигурацией_ПО.md — SCMP (Software Configuration Management Plan). Регламент управления конфигурациями, базовыми линиями и правами доступа.
docs/docs_pwm• PWM_История_эксплуатации.md — описание накопленного опыта использования модуля PWM, обнаруженных проблем в полёте и их решений.• PWM_Неисполненный_код.md — анализ «мертвого» (неисполняемого) кода, причины появления и рекомендации по удалению или изменению.
• PWM_Описание_архитектуры.md — детальное изложение архитектуры: слои, интерфейсы, диаграммы модулей и ответственность компонентов.
• PWM_Тестовое_покрытие.md — матрица покрытия тестами требований; указывает, какие треб. подтверждаются какими наборами CMocka-тестов.
• PWM_Трассировка_кода.md — csv-файл с построчной трассировкой: номер строки → идентификатор требования.
• PWM_Требования.md — полный перечень HLR/LLR к модулю PWM с обоснованием, допустимыми допусками и ссылками на внешние нормативы.
• Журнал_независимых_ревью_PWM.md — записи независимых ревью: состав комиссии, выводы, статус действий по замечаниям.
• Индекс_конфигурации_PWM.md — конфигурационный индекс «Baseline Verified»: список всех файлов, контрольные суммы (SHA-256) и версии.
docs/tool_qual• cmocka_formc.txt — Form C (Tool Accomplishment Summary) для фреймворка CMocka: объём верификации инструмента и вывод о его пригодности.• gcovr_formc.txt — аналогичный Form C для gcovr.
docs/verification• ctest_log.txt — журнал интеграционных тестов (та же структура, но для стенда валидации).• gcovr_report.txt — отчёт покрытия после интеграционных испытаний.
• hil_tz_delay.txt — отчёт аппарат-в-контуре (HIL) по требованию HLR-PWM-02: фиксирует, что выходы переходят в «низкий» уровень < 2 мкс.
docs/trace• PWM_Трассировка_кода.csv — см. выше (включён в список docs_pwm).Поговорил с о3, думал это форумная байка, но нет.
Что говорит наука и надзор — коротко
Подсолнечник действительно «тянет» кадмий из почвы, и яд накапливается в семечке сильнее, чем в большинстве других культур. Это не секрет и для западных, и для российских лабораторий. healthline.com
Нормативы и реальное содержание
* Технический регламент ТР ТС 015/2011 устанавливает предельный уровень 0,20 мг/кг для семян подсолнечника (до 2018 г. было 0,10 мг/кг). Регламент действует на всей территории ЕАЭС. ura.newsspb.aif.ru
* Большие серии проверок показывают, что большинство расфасованных семечек вписываются в норму, но часто подходят к её верхней границе (0,13–0,19 мг/кг). ura.newsspb.aif.ru
* Случаи явного превышения (выше 0,20 мг/кг) фиксируются, но это единицы процентов партий. Россельхознадзор в 2024 г. насчитал 9 «кадмиевых» отклонений из ~300 тыс. анализов (0,003 %). aif.ru
* Независимые экспертизы иногда ловят образцы с 0,21–0,40 мг/кг — то есть в 1‑2 раза выше допуска. petkach.spb.ru
Итого: разговор о том, что «все российские семечки ядовитые», — преувеличение. Но продукт действительно систематически находится «на грани» гигиенического лимита.
Что получается по дозам
* Европейская EFSA оставила предельно допустимое еженедельное поступление кадмия на уровне 2,5 мкг/кг массы тела. Для взрослого 70 кг это ≈ 175 мкг/нед. или 25 мкг/сут. efsa.europa.eu
* Пачка очищенных семечек 500 г с типичным содержанием 0,10 мг/кг принесёт ~50 мкг кадмия (вдвое суточной «безопасной» дозы). Две такие пачки в день устойчиво выводят человека за пределы TWI, поэтому при регулярной «горстевой» диете кадмий действительно копится.
* Период полувыведения Cd из тканей почек 10–35 лет, кровь очищается за месяцы, волосы — лишь «летопись» последних месяцев. pmc.ncbi.nlm.nih.gov
Про подсолнечное масло -
Если коротко
Большая часть кадмия остаётся в жмыхе, а не переходит в масло.
Экстракция гексаном и последующая рафинация почти не растворяют солей кадмия. В промышленности даже есть шутка: «Cd ‑ это проблема кормов, а не фритюра». На научном языке: «Cd концентрируется в шроте, в масле его очень мало» terresinovia.fr.
Поговорил с o3, говорит что карты старые, поддержка давно закончена, и для работы с ними надо старые драйвера, и не будут работать новые фишки ускорения вычислений. Придётся остаться на старых драйверах и библиотеках. А новых дешевых карт на 32Gb не делают. Вот его TL;DR
— MI50 32 GB: 90 % лотов — Radeon VII с наклейкой. Проверяйте PCI ID (0x66A1) и объём. Работает только на ROCm ≤ 6.3, скорость ~2 ток/с на Llama‑70B Q6. Брать стоит, если устроит цена ≤ 20 k ₽ и готовы прошивать/охлаждать.
— MI100 32 GB: новый «sweet‑spot». 750–850 USD, ROCm поддержка ещё жива, ~3–4 ток/с. Пассивный радиатор, но беспроблемней MI50.
— Tesla V100 32 GB PCIe: CUDA 12.x, 600–900 USD. Чуть быстрее MI100 благодаря Tensor Cores, зато памяти впритык.
— Свежих «нищебродских» 32 GB нет: W6800/W7800 стоят 1,3–2,5 k USD, RTX 5000 Ada ~4 k USD. Дешевле только древние MI/V‑серии.
— Склеить две 16 GB‑карты можно (
--tensor-parallel-size 2в vLLM), но PCIe съест выгоду: прирост < 30 %, а сложностей × 2. Без NVLink это вариант «поместить модель любой ценой», не «ускорить».Итого: либо берём один честный 32 GB HBM (MI100 / V100) и живём спокойно, либо готовимся к танцам с двумя 16 GB и скорости уровня одной карты. Чудес дешевле пока не завезли.
самодовайбкодится
На злобу дня: как составить договор, чтобы можно было пользоваться при разработке ИИ агентами? Ведь весь код сливается в облако, а это третьи лица.
Как бы ещё отслеживать включены ли у уборочной машины щетки/пылесос, касаются ли щетки того что они должны чистить и не выходит ли вся убранная пыль через верх в трубу без фильтра. Примерно половина видимых мной уборочных машин в Москве занимаются профанацией - просто медленно едут экономя топливо, а щетка или поднята, или выключена, или пылесос не сосёт и т.п. Но траектория и скорость соблюдается отменно! Нужно ставить датчики мощности на агрегаты машины, чтобы отслеживать их состояние и холостой ход. Маршруты это даже не пол дела.
Больше напрягает поза из которой разработчики на него смотрят. Это вообще что? Прикол? Попытка скрыться от камеры? Может, от роботов пахнет? Или это готовность быстро проглотить капсулу с ядом...
У меня давече с другим проектом gpt o3 имел проблемы с ориентацией по гитхабу, а zip файл он разархивировал внутри и сразу все прочитал. Да и в plus подписке ограничивается число вызовов в неделю, и там и там один - что ссылку дать, что архив. Ну да лирика все это, и так понятно.
Ну почему другой - и тот и этот написали что больше части файлов нет, а именно привязки к микроконтроллерам. Разнится оценка вклада имеющегося кода: один раз он написал что это только скелет с обертками, другой раз решил что это уже половина дела уже. Ну а так-то да, gpt что дышло, как спроси так и вышло
2000-2500р в месяц примерно в зависимости через какие сервисы платить.
Ну вот, говорит, вместо использования кучи аппаратных меилбоксов, как в моём оригинальном драйвере (каждый меилбокс со своим ID и приоритетом) мне придется самому программно засовывать все сообщения в единую свою FIFO очередь и вызывать ваш can_api_transmit_data - но который может ещё и не записать данные, и надо проверять что сообщение ушло через can_wait_tx_done_ll. А оно может не уйти, потому что, скажем, линия занята низкоприоритетными сообщениями, а мне надо отправить что-то срочное. И мне придется отменять отправку текущего сообщения (которое застряло и не уходит) и проталкивать более срочное. Притом что у вас CAN_abort пока и не предусмотрено.
Итого, придется работать с CAN "через одну дырку" делая программно свою приоритизированную очередь, вместо того, чтобы натолкать новых данных в десяток аппаратных мейлбоксов и забыть - сами отправятся по своим триггерам и приоритету (сейчас у меня так). В итоге накладные расходы использования вашего MCAL это не "10-20 тактов процессора" на вызов обертки MCAL, а существенное изменение архитектуры драйвера, который вместо полагания на аппаратные возможности микроконтроллера будет вынужден пользоваться кастрированным узким API MCAL, тратить кучу ресурсов на организацию своих приоритетов, FIFO и менеджера отправки данных в сеть CAN.
Да а как нынче жить-то без этого... это же как вторая голова. Вот пока это пишу, оно мне рассказывает как с помощью Вашего MCAL выглядел бы мой драйвер J1939. Но вообще надо клод брать, вчера вот 4й вышел.
Ну мой o3 - я ему дал весь репозиторий в zip - говорит что всё настоящее, но только верхний слой абстракции, без слоёв микроконтроллеров. И частично рукописное. Цитирую o3:
В папке
mcal_common/лежит ≈ 30 модулей (GPIO, UART, DMA, …).Для каждого «живого» модуля присутствуют:
_general.c— основная логика (state-машины, буферы, таймауты и т.п.);*_commands.c— набор CLI-команд для отладочной консоли;*_diag.c— обход регистров, self-test, счётчики ошибок.Код этой части компилируемый и читабельный — он написан вручную (комментарии, осмыслённые имена, нет признаков автосгенерированного мусора).
Общие макросы
COMPONENT_GET_NODE/CONFIGи ссылки наcode_generator.hпоказывают, что к каждой сборке должен добавляться автоматически сгенерированный файл с описанием таблиц конфигурации (маску выводов, частоты, номера каналов…). Сам генератор (скрипт/утилита) в архив не положен.MCU-специфичного слоя нет вообще. Нет каталогов вида
mcal_stm32f4/,mcal_esp32/и даже простых «заглушек» с прямым доступом к периферии.Поэтому все вызовы вида
gpio_pin_set_ll(),adc_start_ll()и т.п. остаются «висящими».Отдельные модули действительно пока пустые: например,
mcal_common/wdg/содержит толькоwdg_const.hи.mk— чистый каркас без строчки кода.Чем уже можно пользоваться
Алгоритмическая «верхушка». Логика обмена по CAN (очереди, сортировка по приоритету, ожидание TX Ack), I²C-FSM, FSM для I²S full-duplex, универсальные таймерные обёртки, фоновые state-машины PWM/RTC — их можно подключить к своему проекту и «подшить» к собственным низкоуровневым вызовам.
CLI-команды и диагностика. Если заведёте свою систему логов (
log.h) и консоль, уже готов базовый набор команд:adc_init,gpio_toggle,dma_stat, …Make/CMake-инфраструктура. Файлы
mcal.mkиmcal.cmakeумеют по флагам подключать нужные модули, размазывать#define HAS_<MODULE>и добавлять include-пути.Что придётся дописать
Нижний уровень для каждого семейства МК.
Создаёте папку
mcal_<chip>и реализуете функции*_ll()(low level), структуруComponentDriver_t, ISR, карту прерываний. Это 70-80 % работы.Генератор конфигурации.
Скрипт (часто на Python) читает YAML/Excel со схемой платы и штампует
code_generator.h+*_config.c. Без него даже общая часть не соберётся: массивыAdcNode[],GpioPad[],ClockDomain[]просто не объявлены.Сторонние заголовки.
Упоминаются, но отсутствуют:
convert.h,time_mcal.h,none_blocking_pause.hи др. Их нужно либо написать, либо убрать зависимости.Сгенерировано или вручную?
Файлы .c / .h внутри
mcal_common— рукописные. Есть авторские комментарии,LOG_INFO()расставлены выборочно, стилистика единообразна.Автоген требуются только для структур данных (константные таблицы и массивы), на что прямо указывают закомментированные строки
#include "c_defines_generated.h".Итого
Репозиторий даёт полноценный «бизнес-слой» периферии (state-машины, очереди, CLI, диагностика).
Без собственных драйверов и конфигуратора он нерабочий — это половина конструкции.
Писать придётся много: низкоуровневые функции для каждой периферии, генератор таблиц и пару вспомогательных утилит.
Читал-читал и думал - ну вот сейчас автор покажет реализацию своего MCAL на гитхабе, ну или хотя бы примеры, как может быть красиво и абстрактно реализован тот же доступ к GPIO при таком зоопарке подходов. Не говоря уже о каком-нибудь CAN - там даже философия аппаратных модулей внутри микроконтроллеров разная, у кого-то есть куча ящиков, у кого-то fifo сложные и фильтры, у кого-то свой CAN-подпроцессор со своим набором команд.
Не понимаю, как можно тут придумать что-то универсальное и гибкое не получив спагетти-код или не получив ограничение функционала, где через MCAL пролезет 5% от того что умеет аппаратная часть микроконтроллера. Думал, может хоть этот момент автор рассмотрит на каком-то сложном примере, но нет... О чём тогда статья, непонятно. Я как считал что сферический в вакууме MCAL не реализуем, так и считаю.
Ну а что делать, если я хочу LLM для работы с документами организации, которые нельзя направо и налево в API LLM разбрасывать? Мне бы просто загрузить в контекст модели pdf и вопросы позадавать по нему хотя бы. Пусть хоть медленно, но хоть что-то. Так-то да, через openrouter вообще куча моделей доступна как free, в том числе даже deepseek-chat-v3-0324:free. Но провайдеры моделей же все чёрным-по-белому пишут, что собирают пользовательские промпты. На том и живут. А для дома... ну это как хобби проект, чтобы применить знания работы с локальными LLM потом где-то ещё.
У меня Qwen3-30B-A3B-Q6_K под llama запустилась на домашнем компе с видюхой в гигабайт и оперативкой 32. Генерит быстрее чем я читаю! И вроде годноту генерит, ну по крайней мере не хуже gpt 3.5 на глаз