mantech

Да вот сам недавно спрашивал, дали только ссылку на линуксовые исходники...

Почему именно такой выбор, разве V3s был бы не лучше, мелкие платки есть и для того и другого..

Разбирался и оценивал, причем неоднократно, и сказать могу точно, что большинство, кто приходит и говорит "хочу то, хочу это" с умным видом, а при детальном обсуждении выяснялось, что большинство этих хотелок просто взято из статеек инета, типа "круто-же"... По факту оказывалось нафиг не нужно (например всякие вычурные управления жалюзи и пр...) Так же моментально отсевались всякие навороченные контроллеры бытовой техники или сама техника с наворотами управления, все делалось через простейшие ИК трансмиттеры, как правило, оказывалось что нафиг не нужно радиоуправление и умные лампочки - все прекрасно делалось диммерами на RS-485, причем этот интерфейс и был основным в системе, еще надо продолжать?

Удивительно, как люди могут усложнить себе жизнь на относительно несложной задаче. Сначала по каким-то никому не известным причинам заменить простейший RS485 на радио, причем в полностью стационарном исполнении, оправдываясь тем, что раскладывая кучу проводов от нагрузок к щитку им сложно протащить одну витую пару, затем установив какие-то контроллеры с софтом, о котором скорее всего что-то где-то слышали, без ТЗ, с хотелками "маркетолога" - "хочу, чтобы все было управляемым...", только вопрос - зачем? И да, резервное управление всем "умным" хозяйством с помощью обычного "механического" выключателя должно быть обязательно, особенно если используется всякое опенсорсное оборудование и облачные навороты. Начинать героически преодолевать эти трудности без какого-либо плана, постановки задачи и алгоритма решения. Удачи! Без всего вышеперечисленного дров столько наломаете, что лесопилка позавидует. Что тут еще можно сказать

Даже не знаю, что тут сказать А можно было всего навсего уменьшить ток диодов заменив резистор. Например, нужна лампа на 12Вт, покупаем на 15, уменьшаем ток на 10% и пользуемся долго-долго... И никаких жужжалок...

Ну почему так сразу? Лет 5-7 назад, когда такие лампы были с углом меньше 180 град, между матовым стеклом и цоколем была алюминиевая ребристая чушка, и мощность не более 10 ватт - это была фуфлятина, но прогресс идет, кол-во люмен на ватт с того времени стало в полтора раза больше, и теперь эти лампы выглядят куда приятнее, и угол стал больше и мощность. Тут дело просто в банальной жадности и экономии на всем, при этом попытке выжать максимум при минимальной цене, а идея вполне себе реализуемая...

Приветствую. Как-то поднимал здесь тему, как использовать аппаратное ускорение графики в данном камне, т.к. доки на 2 и 3Д ускорители закрыты. На сколь помню, мне sasamy предложил использовать РхР для ускорения вместо ДМА. Вот руки дошли попробовать это дело. Из всех режимов подходящий оказался только ресайз, но в результате обнаружил ограничение связанное с кратностью источника и получателя, оно должно быть либо 8 либо 16, в посл. случае быстрее в полтора раза. Хрен бы с ней, но все это дело виснет случайным образом... Сделал тестовую программу, которая формирует закрашенный заданным цветом прямоугольник. #include "ipu_common.h" #define __REG *(volatile u32*) int32_t ips_rotate_test(uint16_t x,uint16_t y,uint16_t xc,uint16_t yc,uint32_t c) { uint32_t ipu_index = 1,i; // use ipu 1 ipu_res_info_t res_info; uint32_t res_chnl_in, res_chnl_out; uint32_t rot_in_mem = DEV_PXP_BASE; //адрес некэшируемого буфера источника uint32_t rot_out_mem = BG_LFB_BASE; //адрес экранной области uint32_t taskType = PP_TASK; res_chnl_in = MEM_TO_IC_PP_RES_CH11; res_chnl_out = IC_PP_RES_TO_MEM_CH22; for (i = 0; i < 64; i++) __REG(DEV_PXP_BASE+(i<<2))=c; //заполняем 8х8 пикс. константой цвета //set resize idma memset(&res_info, 0x00, sizeof(ipu_res_info_t)); res_info.width_in = 8; res_info.height_in = 8; res_info.width_out = xc-x; res_info.height_out = yc-y; res_info.strideline_in = 4; //1 пиксель res_info.strideline_out = 1366 * 4; //строка пикселей из расчета ширины экрана res_info.pixel_format_in = INTERLEAVED_ARGB8888; res_info.pixel_format_out = INTERLEAVED_ARGB8888; res_info.addr0_in = rot_in_mem; res_info.addr0_out = rot_out_mem+((x+(y*ScrX_MAX))<<2);//смещение на начальную точку ipu_resize_idmac_config(ipu_index, res_chnl_in, res_chnl_out, res_info); //set ic task ipu_ic_enable(ipu_index, 0, 0); ipu_ic_resize_config(ipu_index, taskType, res_info); //enable ic task ipu_ic_task_enable(ipu_index, PP_TASK, IC_PP, 1); ipu_ic_enable(ipu_index, 1, 1); //enable resize idma channel ipu_channel_buf_ready(ipu_index, res_chnl_out, 0); ipu_channel_buf_ready(ipu_index, res_chnl_in, 0); while ((ipu_idmac_channel_busy(ipu_index, res_chnl_out)==1)||(ipu_idmac_channel_busy(ipu_index, res_chnl_in)==1)) ; return TRUE; } Запускаю так: while (1) { ips_rotate_test(0,0,80,80,0xff0000ff); //hal_delay_us(500); } За основу взял их Platform SDK. Итак, вопрос номер раз - почему происходит завис в ipu_idmac_channel_busy(ipu_index, res_chnl_in) ? Т.е. ДМА не может закончить транзакцию и вечно висит в бизи. На сколь я понял эту шнягу, есть входной канал ДМА, который берет данные и пихает их в некую аппаратную шнягу, которая делат коррекцию, растягивание и вторым каналом из нее выкладывает обратно в память. Вроде, как все это должно быть синхронизировано, вопрос чем? входным или выходным каналом, или этой аппаратной шнягой? Вообщем, если после вызова ips_rotate_test вставить задержку, то более-менее работает... Буду рад услышать что-то вразумительное по этому вопросу...

Не спец в трубках, но что-то очень мне кажется, что от 50В ничего не будет, нужно подавать такое же высокое, как в обычном рентгене, а уменьшать силу тока...

То-то и оно... Даже комментировать лень.. MJPEG есть в примерах от СТМ ТС ничего не писал про многопользовательность. Про защищенную передачу тоже. А с какими данными он работает? И вообще, я че-то одного не понял, что в линуксе это все сделается по взмаху волшебной палочки?

И чего там такого чудовищного? Получить картинку кинуть ее в аппаратный кодек и потом перекинуть в эзернет или куда-то еще? с наличием примеров работы этих блоков от производителя... Такое впечатление, что все, что сложнее веб-термометра чудовищно сложно и реализуется только на линуксе... Честно если бы самому пришлось делать подобное, то самая сложность была бы в протоколе поверх UDP\TCP, который понимают все эти смарты и планшеты... Думаю, это самый лучший вариант для этой задачи...

В том-то и дело, что все это как раз настраивается средствами ОС, по крайне мере с кликами настраивал нормально в свойствах мыши, а вот расположение точки координат 0.0 я ни на одной матрице не видел кроме, как в левом верхнем углу. Откуда эти производители взяли экраны с этой координатой в нижнем углу или в правом мне просто непонятно... ЗЫ. Конечно можно тут всех распинать, кто делает подобные "шедевры", но делу это не поможет, да и тачскрины эти в основном предназначаются не под винду, линукс и пр ОС, а под свою разработку, на стандартных осях я просто проверял их работоспособность, поэтому не нашел ничего лучше, чем добавить в файл конфигурации 3 параметра - смена осей X Y, зеркалирование X и Y. Думаю, этого будет достаточно и пользователь при смене разбитого экрана, сможет поменять там настройки, если новый окажется несколько "другой"... Всем спасибо за ответы.

Ясно. Думал, что встроенными средствами ОС можно что-то сделать, но видимо увы и ах, придется клиентам про драйверы объяснять... ЗЫ. Честно говоря непонятна логика тех, кто делает такие контроллеры, почему нельзя сделать стандартно...

емкостной - ilitek 2510 резистивный партномер платы TS0402US, на чипе что-то невразумительное. Разъем рез. панели переворачивал, с горизонтали глюк переходит на вертикаль и все, поотдельности пины перетасовать нельзя - там гибкий плоский шлейф.

Это будет проблематично, куплено на алиэкспрессе, они там даже порт перепутали при первом заказе,это ж китайча...

Это нужно драйвер пересобирать или конфиг править?