gormih

d/ε_экв. = d1/ε_воздуха + d2/ε_диэлектрика... Зачем все усложнять, строить модели?

Не знаю, на сколько данный вариант подойдет... но точно знаю, что в научной библиотеке Саратовского Гос. Университета должен быть полный архив.

Диагноз: Флешка испорчена. Как исправить: Обратиться к производителю/поставщику сего чуда. Другого ответа дать не возможно, так как не понятно что за оборудование как минимум.

Рискну предположить, что если денег отвалить майкрософту все таки охота - можно тупо позвонить в их саппорт, и представиться корпоративным клиентом. Там быстро ситуацию разрулят.

Ну это да. Теперь другое - как все это будет выглядеть в производстве, если оно хоть сколь нибудь серийное? Мне лично смешно, если не грустно за нашу электронную промышленность и за такие вот извраты. И по теме... с китайцами все равно конкурировать не удастся: http://www.ebay.com/itm/TP-Link-TL-MR3020-...=item20d4ebe180 Берите сразу готовое и суйте в свой корпус - это дешевле.

Слабо верится. http://pinouts.ru/Slots/pci_express.shtml http://prohardver.hu/dl/upc/2011-09/280405...420_alaplap.jpg Как то не катит...

1) Воспроизвести с изменениями = разработать (в данном случае практически с нуля). 2) PCI-E ничего общего с USB не имеет. 3) Задача вполне решаема, но вероятность того, что ее успешно решит фрилансер равна практически нулю. Основной подводный камень в данном случае именно постановка на производство.

Самый главный баг то по сабжу - то что нету исходников на самом сорсфорже. Отсюда полезность равна нулю.

Да без проблем. http://www.gentoo.org/

Не думаю, что баг в busybox Может, добавить побольше printk в модуле ядра для пущей ясности?

Применительно к встраиваемым системам: В 90% случаев само ядро ничего не ищет. Именно по этой причине существуют всякие там древа устройств. И написать драйвер формально не всегда есть окончательный результат. Получить устройство с произвольным названием в /dev/ или /proc или sysfs вообще не проблема. Проблема в том, чтобы оно реально заработало, и не вешало например ядро в spinlock :-)

Не обнаружил достойной документации по данной подсистеме. Исходники рыть ... как то не айс. Кто может порекомендовать что нибудь дельное из книг/достойной документации? В идеале, как вообще цеплять i2c + i2s на dai + snd_card Вообще идеально - работающий max98089 :-) Распишу поподробнее... В BSP прописал интерфейс i2c, адрес 0х10, max98088 Скомпилил ядро c all asoc codecs. В результате наблюдаю в /proc/asound/codecs max98088 Так как система андроид, то в /sys/kernel/debug/asoc/codecs есть max98088.1-10 Теперь вот траблы прицеплением сего к DAI и SND_CARD. Готовые исходники для другой EV_BOARD создали в debug/asoc мифическую поддиректорию с непонятным соержимым... ахочется получить soundcard, которая как бы там прописана.

Кто из опытных людей может подсказать/прикинуть, какой мощности должен быть передатчик на данной частоте, что бы на удаленной антенне в зоне прямой видимости на расстоянии 100 метров была достигнута мощность 10 dBm?

Для того, чтобы это сделать нужно как минимум хорошо знать структуру ОС, и как ее портировать на конкретный процессор? Или я в чем то заблуждаюсь? Карта регистров не меняется разве? Перечень оборудования? Это все надо где то прописать. А на это далеко не всегда есть время. Желательно иметь готовый вариант.

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

Нужна ОС реального времени, которая уже портирована под OMAP 1808, либо которую можно в кратчайшие сроки портировать. Интересуют как коммерческие продукты, так и с открытым исходным кодом. Прошу помощи - подсказок, на что обратить внимание.

Проблема будет с поддержкой u-boot вашей SD-карты. Если проблему решите - можно все :-) Ядро собирается из исходников. Исходники берутся например с kernel.org, на них ставятся патчи и билдятся. Так же исходники ядра для Вашей платы есть на сайте атмела. Потому же, что и пункт 1 :-) Безопасный запуск - это когда создается "теневая" область для ядра в ОЗУ, и ядро запускается уже оттуда, а не посредственно с носителя. Это позволяет избежать риска порчи ядра в результате случайной записи данных на носитель во время сбоев

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

Точно где то встречал. Еще спрошу у человека. А вообще есть вот такой вариант например. ARM конечно ограничен в dsp инструкциях, но все же. На счет конкретно DSP + FPGA еще узнаю :-)

Есть такие чипы - DSP и FPGA в одном корпусе (чипе). Их достаточно много. Имхо самое то для Вас :-) А многоядерные чипы могут и не оправдать Ваших надежд... Тут как бы самое узкое место - как раз взаимодействие ядер между собой и с аппаратурой через всякие "интеллектуальные" штуки, которые могут достаточно неадекватно вести себя для Вашей задачи. (Не зная сути задачи трудно судить)

Потому что собрать самому ядро для одного процессора будет значительно сложнее, чем для двух. Для двух уже есть готовые реализации, которые нужно чуть подработать. Для одного Вам нужно будет славно потрудится, чтобы запустить хотя бы ядро Linux- дело неблагодарное имхо, но если есть много времени и высококлассный спец по портированию Linux ядра на новые платформы - почему бы и нет :-)

Сделать можно все. Самое узкое место в Вашей системе - общие шины для оборудования и памяти от ядер. И еще будут некоторые проблемы с объяснением линуксу на каком ядре он должен работать, и на каком запустить вашу отдельную задачу (запускать ее будет именно линукс, тут без вариантов). И кстати - ваш кортекс-а9 имеет 4 ядра а не 2.

Исчезновение линка происходит не мнгновенно, это надо понимать... Если ты дал команду на закрытие линка, а после команду на зарытия сокета - это вовсе не значит, что вначале закроется линк, а потом сокет. Из за этого и память утекает. Рекомендуется делать паузу ... на сколько большую - зависит от платформы и ОС :-) И кстати под QT такой проблемы быть не может в принципе. :-)

Ясно. А разве готовых gnu стеков нет? Если есть - они и будут тем самым примером... который нужно только адаптировать под ARM :-)

Дело в том, что у ARM есть такое устройство как USART, и у него есть такой режим работы, как IrDa ... Я вообще всегда думал, что мы просто настраиваем USART на работу как IrDa, и просто начинаем писать/считывать данные из нужных регистров по их готовности. В чем я не прав?