Harbour

gmail китайцы рубят периодически, так что это как повезет (http://magazeta.com/chinese-internet/2009/06/25/v-kitae-zablokirovali-google/). Разницы в написании между провинциями нет, есть только в произношении. было прикольно видеть китайца с севера который обьясняется с китайцем с юга по english, так как на родном - "тим бу дон", шо по нашему - "ни бум-бум"

Верю, реалтек есть реалтек, чего не скажешь о китайских 10 долларовых свитчах

сейчас мало свитчей является полнодоступными - т.е. если свитч на 8 портов то в идеале он должен обеспечивать 100% скорости при загрузке всех 8 портов. в жизни свитч редко загружен на полную мощность, т.е. скорость коммутации, для экономии на железе, обычно варьируется в пределах 80%-100%. это значит что в моменты перегрузки он не успевает переслать/скоммутировать пакет - отсюда и потери. также следует учитывать что ICMP ответ дает комп со всем наличествующим в нем софтом и железом, которое тоже может глючить. т.е. нужно убедиться что потери в сети именно на транспортном уровне.

обзор http://www.seattlewireless.net/index.cgi/D...SL-G604Thacking конкретней http://mcmcc.bat.ru/dlinkt/kernel/build_kernel_rus.txt http://mcmcc.bat.ru/dlinkt/FW_dsl-xxxt_README.eng.txt

В дополнение про студии - «Титаник», «Послезавтра», «Я, робот», «Пятый элемент», «Стартрек», «Интервью с вампиром» и многие другие фильмы со спецэффектами считались на Linux, а именно на Nuke - D2 Studio проекте основанном на FLTK

в дополнение : http://www.linux.org.ru/view-message.jsp?m...d=1247752241441 http://blog.internetnews.com/skerner/2009/...econd-boot.html

Различия, как уже было логически доказано, в способе работы с USBBB2 - в linux версии (jtagd) альтера чего-то намудрила своего, так как даже старый синхронный libusb v0.1 _так_ тормозить не может

у меня на desktop'e мамка годичной давности asus с express gate - это linux с X'ами на vesafb - грузиться за 5 sec из SPI (!) флеша + HDD. для скоростей в < 1 sec действительно применяют suspend-to-disk с выбором storag'а с соотвтетсвующей скоростью. на x86 железе, для достижения нужной скорости, это все дело нужно прошивать всесто биоса

К тому же к кажному warning'у help прилагается (правой кнопкой кликаем на нем) - с подробным описанием самого warning'а и способа его устранения. Как уже правильно заметил SM, в Вашем случае выводы нужно размещать в разных банках, питать их тоже соответственно.

mmap-то быстрее, но ведь все равно SPI в конце, дисплей все равно будет перерисовываться на несколько порядков медленней чем выполняться самый тормознутый write. Здесь в любом случае нужна flush-стратегия - в идеале обновлять нужно только измененные пикселы.

Не ... вылететь оно точно не сможет. Я опасаюсь, что если запустить в серию, то может выйти следующая ревизия кристалла, в которой эта фигня или не будет работать или будет работать как-то по другому. Чтобы проверить другие значения мне нужно устройство снаружи переделывать - это сейчас невозможно. Теоретически это все можно проверить через loopback.

Чем я там ограничился или нет - это мое личное дело и к обсуждаемому топику отношения никак иметь не может. Люблю, знаете-ли подправлять свои сообщения - чтобы лучше доходили для тех кто константно не догоняет ... А кто здесь изображает склеротичную бабушку, думаю и так видно - тут это забыли, тут на это забили ...

Читать это незачем, так как C3 прекрасно работают с PCI 5V, несмотря на некомпетентные советы. Это от моска зависит - если сложно удержать в голове больше одной вещи, то можно по очереди ими жонглировать ;)

Смысл использовать mmap при последовательном обмене в конце ? В данном случае юзают стандартый open/write. Насчет callback'ов - кажись в vm_area_struct есть указатели на f()-ии типа swapout/nopage/sync - вот последняя при каждой записи и вызывается.

Нужно было загнать 8xE1 по одному сериализатору (64 слота выходит). Вроде работает, вопрос чем это могет грозить, так как из доки ясно следует что данные биты Reserved ?

Дык, если сам себе босс - то нафига канитель ? GPL и никаких гвоздей.

Кому забыть ? Хе-хе, всему миру что-ли ? Еще раз - внимательно (!) идем на сайты ведущих производителей мат-плат и убеждаемся в версии PCI спецификации выпускаемых в данный момент моделей. Другое дело что про PCI вскоре можно будет забыть на consumer рынке, но для industrial он как Ленин ! ;)

следовало бы с работодателем эти вопросы оговорить и устаканить, что бы не вылезало подобное в середине проекта, потому как теперь есть куча моментов, например сборка части приложения под Linux подразумевает использование libc и ее header'ов - она как известно LGPL и это как ни крути есть "combining" ;)

Hi, Заказчику необходимо комп юзать от -15C до +55C, я так понимаю при отрицательных T там должен быть подогрев. Кто сталкивался - где их взять - вопрос цены не стоит никак. Thanx

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

Так можно - главное чтобы libtclxds.so не содержала в себе libusb ни в каком виде, токмо как в dynamic linked, неважно через какие промежуточные либы. А то что Freeware или ХренWare - если недоступны исходники, то уже нарушаем LGPL. А гембель в том, что никто модуль этот собирать сам не будет, по причине того что binutils/gcc/kernel headers мало у кого стоит - и придется или как у Nvidi'и иметь херову тучу уже собранных или писать инсталлятор. тут наступаем на новые грабли, так как у юзеров N^N вариантов конфигурирования ядра, X^Y вариантов binutils/gcc - будут присылать неудачные логи, придется их разгребать и решать одни и те же вопросы, которые давно описаны в факе, который, в свою очередь никто не читает ... и все это на расплодившемся множестве дистров ... вобщем волосы дыбом на одном месте обеспечены. То ли дело бинарная libusb - кинул и забыл

Гы ;), не конает - коммерческая программа, не должна, по LGPL, содержать внутри свободного обьектного кода, допускается только динамическая линковка. Че за проблем - слепить S/RPM с libusb-1.x или просто положить ее вместе с прогой - этого никакая лицензия не запрещает. Драйвер будет не сложнее, чем вариант с libusb, но гембеля по сопровождению в N раз больше.

До спины как ее линковать, если не стоит вопрос с лицензией. качают ее обычно с SF. LGPL (есть где-то фак в сети на русском) подразумевает использование в коммерческих проектах при динамической линковке и предоставление всех исходников/обьектных файлов при статической. Т.е. линкуем динамически - и ничего открывать не нужно. Альтера когда-то применяла libusb, сейчас, судя по предварительным результатам дизассемблирования, они работают напрямую с usbfs - т.е. ничего и никому они не обязаны.

Стандартизация dev tools очень сильно продвигает разработку по следующим, первым же пришедшим в голову причинам : - Стандарт по набору dev-утилит, их опциям и документации: 95% опций линкера/компилятора/ассемблера и т.д. не меняются, меняются только оставшиеся 5%, относящиеся к оптимизации под конкретную платформу. Также очень немаловажный фактор играет качество парсеров и сообщений об ошибках/warning'ах средств разработки - на кой разработчику держать отдельный набор бубнов под каждую среду ? - Стандарт в надежности самих средств разработки: например, судя по DefectHistory.txt, ti писал компилятор почти с нуля, что глупо и затратно не только с финансовой точки зрения, но и с точки зрения пользователей, которые вынуждены через support обнаруживать/фиксить ошибки в ихнем компилере, вместо того чтобы им пользоваться (уже молчу о заплаченных $4k и, самое главное - потерянном времени). GCC уже давно прошел эти детские стадии, к тому же база пользователей и скорость обнаружения/исправления ошибок не сравнится ни с одним существующим компилером. - Стандарт на средства отладки: если честно, я думаю многие, и не только на этом форуме, уже задолбались изучать/использовать многообразие JTAG и Soft отладчиков, каждый с собственными долбанутыми ньюансами и такими-же разными интерфейсами. Порт openocd/gdbstubs под свою платформу - что еще нужно простому ковбою - Единство поддерживаемых C/C++ стандартов: - код, который портируется, очень часто написан разными людьми с использованием разных стандартов - хочеться иметь широкий диапазон их поддержки, дабы зря не перелопачивать, [ а иногда и переписываать ] его под новый замшелый компилер - Стандарт на LIBC/Posix/threads/OpenMP: - конечно разница лечится написанием недостающих функций/библиотек и изучением особенностей поведения существующих, но это опять же лишняя и никому не нужная работа - Стандарт на средства coverage и profile: - Стандарт на расширения/plugin'ы и портирование на другие платформы: весьма актуально для людей пишущих под заказные/свои FPGA процессоры Таким образом - качество development средства (которое, ясен пень, прямо влияет на качество и скорость разработки) - это не конкретная выдернутая из контекста фишка какой-то его части - а целый комплекс задач разработки, которые это средство должно решать. В случае с GCC-flow, программист изучает только application-specific area, будь-то архитектура части процессора или непосредственно сама задача. в случае с proprietary вариантом - время, увы, уйдет на изучения относительных качеств травы индусов, которые ее курили в момент создания этих средств. Особенно прикольно при этом читать недоумения TI менеджмента, по поводу того, что чипы, мол хреново продаются ;) Радует, что не все такие тормоза, как TI - есть примеры и удачных решений - см. for ex. NIOS/AVR32/BlackFin.

async режим поддерживается в libusb-1.x, как уже было замечено в треде по altera jtagd. там при заполнении структуры операции есть поле libusb_transfer_cb_fn - callback ф-ии, которая вызывается при ошибке/завершении операции. треды libusb всегда херово поддерживала, но при наличии async интерфейса они собственно и не нужны. альтернатива libsub, насколько мне известно - это написать модуль/драйвер своего устройства в ядре.