adnega

Заявлялось Это больше одного человека. И несмотря, но кучу восхитительных отзывов, никто не повторил. Что меги128 ни у кого нет, симов старых или пары выходных? Давайте под "запустить Linux на ядре X" будем понимать возможность собрать из исходников систему под данное ядро. И будем отличать от эмуляции других ядер с запуск ПО под эмулируемое ядро.

Есть подозрения Мне тоже кажется фэйковатым. Есть схема (причем ужасная), исходники, но хоть кто-нибудь смог повторить? Но даже если и удалось сэмулировать проц, то справедливости ради, это PXA255, т.е. формально Linux запускается не на AVR. Иначе можно вообще сказать, что Linux работает на ГЭС, т.к. она тоже является частью схемы.

Если это широкоизвестный факт, то, может, дадите ссылку?

Я сам с усам, поэтому не особо интересуюсь курсами/выдеокурсами. Рекомендую подписаться на новости и следить за мероприятиями Компэла. Раньше они в Москве и Питере проводили семинары по STM32, а на практической части раздавали отладки (бесплатно).

Начните с видео.

Задержки видел по 500мс и больше. За 10 лет карты сильнейшим образом подешевели. Вроде, MMC-карты в плане потоков выглядят лучше, но не по цене. Кста, карты со временем начинают "тупить" даже если работает только на чтение. Если найдете "крутую" карту с "ровными" характеристиками ожидания, то дайте знать. Могу поделиться некоторой статистикой, если надо. Доля обмена между картой и SDIO ничтожна по сравнению с ожиданием данных от карты. При "ожидании данных в 500мс" будет обмен между картой за 0.5мс или за 2мс уже не так важно. Где можно взять такие карты? Производитель? Модель карты?

Есть мнение, что "ключик" можно заменить на пачку передергиваний SCL, пока SDA стабильно не придет в "лог. 1".

У каждой модели есть границы применимости. В границах модели показывают результат с заданной погрешностью. За границами модели не работают. Сейчас границы очень широки и наблюдать новый эффект без экстремальных условий (низкая температура, высокое давление или магнитное поле) уже не получится. Можете использовать сегодняшние модели смело, ибо нет у вас ресурса, чтоб выйти за границы. Взять формулу сложения скоростей. Все знают, что она приближенная, но в большинстве задач обычные пользователи не используют релятивистскую формулу.

Слесарь изобретает хладогент на нанороботах с эффектом туннелирования! Но все изобретено до нас - "демон Максвелла". Вот если бы была реализация "демона", то не нужны были бы эти испарители, конденсаторы, хладогенты...

Еще: по ссылке удалось на 10-15% поднять мощность холодогенерации за счет дополнительных 150Вт. С одним излучателем КПД не изменился, с двумя якобы поднялся на 8%. Можно разными способами повышать эффективность. Вы предлагаете энергозатратный. Причем эта энергия будет вкачиваться в систему, и пока она пойдет на "затыкание конструктивных ошибок" КПД может повышаться, затем неминуемое ухудщение КПД. По предоставленному вами доказательству следует, что чем больше ультразвуковых источников тем лучше: один ничего в плане КПД не дал; два подняли КПД на 8%. Логично предположить, а с чего нет эксперимента с сотней источников? Авось КПД за 1000% бы перевалил? Сможете ответить? На сайтах самогонщиков в разделе "ректификационная колона". Существуют целые "матан-батлы" насчет оптимальной формы.

Пух это 10%, а прах 15% Считайте это изначальной ошибкой при проектировании системы. Т.е. исходная система была не оптимальной и за счет оптимизации еще КПД подняли. Можно было медными пружинками засыпать испаритель и медленно вращать, чтоб увеличить площадь испарения. Да, раздробленные капли могут лучше осаждаться на трубку и на ней испаряться, но если у Слесаря капли летают как мухи, то конструкция прежде всего плохая, а не теория. Теория, кста, не моя. Законы сохранения и начала термодинамики никто не отменял.

Чистая молекулярная физика. Молекула воды в капле удерживается определенными силами. Одно дело взять и механически разорвать все связи, т.о. превратив жидкость в пар. Другое дело подогревать. Тут уже все гораздо медленнее, т.к. система находится в термодинамическом равновесии. При данной температуре, давлении и влажности часть молекул покидает каплю, а часть прилетает новых. Покидают каплю только самые "энергичные", т.е. теплые молекулы. В итоге, если из миллиона молекул половина самых горячих улетит, то средняя температура капли будет меньше, она как бы остынет. В холодильнике капля должна войти в тепловое равновесие с трубкой. При данном давлении насыщенных паров и температуре, статистически будет происходить испарение с понижением температуры капли и соответственно трубки. Если просто размельчить капли в туман, то влажность может быть превышена и капли не то что испаряться не будут, а будут конденсироваться.

Вроде, уже обсуждали. Кто-то путает причину и следствие... Капелька испаряясь забирает тепло у трубки - трубка охлаждается.Если вы ультразвуком будете превращать капельку в пар, то капелька сделает это с удовольствием, взяв всю энергию от ультразвука, а не от трубки. Итого: капелька испарилась, а трубка не похолодела. Зачем нужен такой холодильник? Непонято, где там летают мухи? Может тупо накидать медных спиралек оптимальной формы (как в самогонной колоне)? Или установить трубы так, чтоб ось трубы не совпадала с направлением g (вектор тяготения земли). По моему очевидно, что любая подкачка энергии на испарение только ухудшает производительность холодильника. Нужно принимать конструктивные меры повышения оптимальности без подвода энергии.

Считать, но правильно. Зачастую фильтрация - это сложение с накоплением произведений пар чисел. Нужно все перемножить. Полученные значения расставить по возрастанию. Суммировать от меньшего к большему. Так ошибка будет минимальна.

Попробуйте 400x240. Попробуйте записать в видеопамять напрямую, без DMA2D.

Я не спец по HAL, но displayLayer1.ImageWidth = 0; displayLayer1.ImageHeight = 0; по-моему, не должны быть нулевыми.

Это плохо. Лучше перенести фильтрацию на низкую частоту дискретизации.

Кусок кода покажете?

Сдвиг на 6 разрядов можно заменить на умножение на константу 2^6. Эту константу можно внедрить в коэффициенты фильтра. Есть команды МК для преобразований int во float и обратно.

Нужно проинициализировать экран со всеми таймингами под полное разрешение, но при инициализации слоев (а именно они используют видеопамять) можно указать буфера меньшего размера. Границы будут залиты цветом фона, который можно выбрать. Можно один из слоев натравить на ПЗУ, тогда будет выводится статический логотип к примеру. Можно попробовать анимировать этот логотип, перезависывая адрес начала видеобуфера синхронно с ходом луча :) PS. Я так делал - работает, но при определенных соотношениях размеров.

Сам Матлаб может дать вам характеристики фильтра с учетом квантования. Целочисленная порой сильно уступает ПТ даже одинарной точности. Я вообще написал фильтр на asm //--------------------------------------------- // fpu_iir //--------------------------------------------- .thumb .thumb_func .global fpu_iir .type fpu_iir, %function fpu_iir: .cfi_startproc cbnz r1, fpu_iir_load bx lr fpu_iir_load: push {r0-r4, lr} VPUSH {s0-s7} // load f VLDR.F32 s1, [r3, #0] // G VLDR.F32 s2, [r3, #4] // a1 VLDR.F32 s3, [r3, #8] // a2 VLDR.F32 s4, [r3, #12] // b VLDR.F32 s5, [r3, #16] // tn-1 VLDR.F32 s6, [r3, #20] // tn-2 fpu_iir_loop: // load ldr r4, [r0], #4 // s0 <- x VMOV.F32 s0, r4 // calc tn VMUL.F32 s7, s1, s0 // G * x VFMS.F32 s7, s2, s5 // -a1 * tn-1 VFMS.F32 s7, s3, s6 // -a2 * tn-2 // calc y VADD.F32 s0, s7, s6 // tn-2 VFMA.F32 s0, s4, s5 // b * tn-1 // save t VMOV.F32 s6, s5 // tn-2 VMOV.F32 s5, s7 // tn-1 // y -> r0 VMOV.F32 r4, s0 // store str r4, [r2], #4 subs r1, #1 bne fpu_iir_loop VSTR.F32 s5, [r3, #16] // tn-1 VSTR.F32 s6, [r3, #20] // tn-2 VPOP {s0-s7} pop {r0-r4, pc} .size fpu_iir, .-fpu_iir .cfi_endproc

Не нужно дергать перезапись после каждого срабатывания. Обнуляйте цепочку из битов во флеш исходя из: "1 бит = 100 срабатываний". При этом нужно прикинуть общий ресурс срабатываний. 10 миллионов достаточно?

>500 устройств в любом случае поддерживать не просто. Если сделать поверх VPN, то конфигурировать нужно только роутер. На устройствах можно обойтись DHCP. Правда, сервер будет не совсем сервер )) По сути он будет клиентом для камер, т.к. камеры будут серверами и будут отдавать картинку по запросу.

У меня сделан VPN (OpenVPN) на роутерах Микротик между двумя квартирами. Пользуюсь не на полную катушку, но проблем со стабильностью не видел. Могу смотреть 4 камеры с другой квартиры. Порты никакие не пробрасывал, т.к. логически они в двух соседних подсетях (прописал маршруты). При добавлении новых узлов в подсети ничего прописывать не надо. С широковещательным трафиком не заморачивался. Просто для каждого скопища камер нужно выделить свою подсеть. По моему, это гораздо легче админить, чем нестандартный самописный модуль, который рискует быть не совместим с камерами, кодеками, ключами и т.п. Кста, а камеры умеют VPN-клиентиться к серверу?

О опрашивать камеры напрямую (через VPN) с сервера почему нельзя?