gerber

Ну не скажите! Прикосновение к площадке дозатором по времени существенно короче, в разы, чем прикосновение паяльником. Ручным дозатором можно ставить точки пасты "как из пулемёта". А паяльником каждую площадку нужно ещё и прогреть, да ещё и припоя набрать для неё. Другое дело, что расстановка компонентов на точки пасты требует некоторой сноровки, чтобы не смазать пасту, но это приходит с опытом.

О да, без обработки изображений сегодня никуда ! Приклеиваете к стенке 2 пьезодатчика ЗП-1 ("один раз вверху - а другой раз внизу" (с) ) - и все дела. Главное - разделить верхнюю и нижнюю часть стенки любым механическим способом. Пьезодатчики подключить к микрофонному входу звуковой карты компьютера и написать программу из 300 строк.

Очень приятно видеть чётко и грамотно сформулированное техническое задание. Но пара вопросов всё-таки остались неясными для исполнителя - какого цвета светодиоды должны быть использованы в пульте? И ещё - допускается ли мигание светодиода HDD, или исполнителю предстоит устранить и этот недостаток, распространённый в большинстве персональных компьютеров по сей день?

ИМХО, даже если удастся затолкать более толстую плату вместо платы стандартной толщины - не факт, что подпружиненные контакты сохранят надёжность прилегания контакта к площадке на плате, тут всё будет зависеть от конструкции разъёма, а она может быть разной. Поэтому я бы не стал закладывать в конечное изделие увеличенную толщину, и лучше бы "закрыл глаза" на волновые сопротивления.

Можно приклеить полосочки скотча на любую плату PCI-E и попробовать ... :laughing: А в чём проблема изготовить плату нужной толщины ?

Ни о какой сети речи в ТЗ не идёт. Написано же - датчики по очереди включают свои передатчики и передают данные. Всё поместится в одну RF-микросхему за 2 уе, внутри которой уже есть и процессорное ядро, например, фирмы Nordic .

Для 50 тыщ евро в год достаточно хорошего знания МКАДа - не говоря уже про ПКАД. (с) Ашот

Я так и не вкурил, почему тема называется "Вторая жизнь в радиоэлектронике, цифровой радиосвязи"? А где же первая жизнь?

Хотел бы я посмотреть на банк, который выдаст гарантию по оплате фрилансерских работ частного лица, и примет под это дело депозит ;) Можно ссылку на подобные банковские предложения ? И что, кстати, будет с депозитом, если заказчик не выдаст акт приёмки работ, несмотря на их завершение? Правильный ответ - возвращается держателю депозита. Поэтому такой механизм оплаты ничуть не отличается от простого добровольного перечисления денег заказчиком на карту исполнителя по окончании работы. И ещё - указали бы город, где Вы находитесь.

А что за CD-карта фигурирует в ТЗ ? Бывает либо SD, либо CF. Или речь идёт о записи компакт-дисков? UPD: опередили ...

Не подскажете, кстати, что за принцип? Как получают разрежение в простых пневмодозаторах, ведь не вакуумным же насосом, извне только пневмомагистраль с избыточным давлением.

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

Интересно, как таким способом можно вызвонить цепи, которые не выходят на поверхность, а полностью разведены во внутренних слоях?

Есть серийное изделие на базе процессора AT91RM9200. Процесс заливки прошивки в изделие организован через UDP (USB Device Port) следующим порядком: - пока прошивки в плате нет (в терминале DBGU бегут буквы CCC), USB-устройство, которое появляется в Windows обслуживается атмеловским драйвером DFU. Приложение Win32 через этот драйвер заливает туда первичный загрузчик, который грузит в память уже основной софт для прошивки всех имеющихся на плате флэш-модулей; - этот софт представляется системе, как USB device с двумя конечными точками (помимо нулевой) - Bulk OUT и Bulk IN с размером пакета 64 байта. Далее весь обмен идёт через эти endpoints. В частности, для заливки флэшки туда передаётся довольно большой объём данных через Bulk OUT endpoint, постранично, по 528 байт. Приложение вызывает функцию WriteFile(...), драйвер разбивает эти передачи на пакеты по 64 байта (8х64 и последний пакет 16 байт). Внутри ARM приём данных организован довольно примитивно, поллингом - крутится цикл опроса поочерёдно статусных битов AT91C_UDP_RX_DATA_BK0 и AT91C_UDP_RX_DATA_BK1, по мере возникновения этих событий выгребаются данные из FIFO, после чего соотв. бит сбрасывается. Всё это работало и работает до сих пор. Но пришла новая партия плат, где в процессе передачи блока данных на Bulk OUT endpoint в какой-то момент (где-то в середине заливки) происходит сбой - в USB-снифере видна ошибка 0xC0000005 - Device not responding, соответственно, WriteFile(...) возвращает ошибку. Со стороны ARM-ового приложения видно, что пакеты от хоста перестали поступать. Осциллографом смотрел сигналы на DM,DP линиях - не отличаются визуально от тех плат, где сбоя не происходит. Ещё попробовал поменять между ними кварцевые резонаторы 12 МГц - проблема остаётся там, где и была. Errata в части UDP-подсистемы RM9200 чиста. Схема подключения UDP к хосту сделано точь-в точь по даташиту. Что ещё можно посмотреть и попробовать для выявления и локализации проблемы ? Где могут теряться пакеты ? Если проблема в софте - то в чём она ? Наиболее вероятная версия - неуспевание выгрести из FIFO со стороны ARMa - в этом случае действительно посылается NACK. Но там негде возникнуть задержке - бесконечный цикл, который только и занимается тем, что опрашивает статус и выгребает данные...

Если дело только в этом - то такие "мелочи" не останавливали ещё ни одного оверклокера.

Дело за малым - научиться эффективно распараллеливать ПО. :tort:

На QNX намекаете ? :laughing: Пользователи нормальных операционных систем, как известно, не ищут лёгких путей и сами решают свои драйверные проблемы. Это Вы о чём? Что мешает магнитоле различать два разных USB ключа и в зависимости от воткнутого менять свои настройки?

Юзер должен же как-то запрограммировать под себя такого рода устройство - как оно должно себя вести, индивидуально для себя. Поэтому так или иначе без своего драйвера и утилиты не обойтись. А установку драйвера можно автоматизировать - при первом подключении USB устройства оно должно "выглядеть" как USB-флэшка с записанным драйвером. Ну а если autorun.inf не заблокирован - то и драйвер сам инсталлируется, можно так сделать.

int main() { __asm{ #include "avr910.asm" } return 0; } Жду 500 рублей. :laughing:

Идеологически правильным решением будет организация цепочки буферов DMA (например, 256 буферов по 600 кБ), указатели на которые организованы в кольцевой буфер. Это позволит рассинхронизировать полностью потоки, управляющие захватом данных и записью на диск. Думаю, что идея очевидная и понятная - поток, управляющий захватом начинает по очереди заполнять буфер за буфером, при достижении определённого порога (скажем, заполнено 16 из 256 буферов) начинает работу поток записи на диск, опрожняющий буфера. Тут главная задача - добиться, чтобы затянувшаяся операция записи не приводила к остановке потока захвата данных. Цепочка буферов позволит снивелировать спонтанные задержки, вызванные записью на диск, но не решит проблему, если задержка носит систематический характер, в этом случае нужно искать другие архитектурные решения.

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

Если ОС не запускается в виртуальной машине - к ней теряется доверие, что-то не так. У меня, например, зависла. Значит, есть какие-то жёсткие аппаратные завязки. Это плохо по определению. Да и как вести разработку под неё? Не каждый согласится выделить отдельный комп под Kolibri OS.

В огороде бузина, а в Киеве дядька. Возможность синхронизировать время по сети никак не гарантирует, что UDP пакеты дойдут до получателя строго с тем же интервалом, с каким вышли от отправителя.

Когда-то пару лет тому назад тоже озадачивался таким вопросом и прошерстил много китайских предложений. Да, в Китае есть много предложений мини-фрезеров, приличные в районе 1,5-2 тыс. уе. Но в итоге, подсчитав стоимость доставки из Китая 100 кг (плюс 2-3 месяца ожиданий, если хочется доставку по минимальной стоимости), страховки, растаможки (+30% + расходы на брокера), погрузки-разгрузки, и, главное, риск получить "кота в мешке" - понял, что выгоднее получается купить уже здесь, у тех, кто ими занимается профессионально и даёт гарантию. В итоге купил здесь . (не реклама).

Действительно, абсурдная постановка задачи. Первый же встретившийся на пути пакетов UDP роутер или даже Ethernet-свич сломает любой жёсткий интервал следования пакетов. Поэтому упираться в ОС бессмысленно. Для таких задач нужно смотреть в сторону синхронных коммуникаций. И, кстати, реалтайм тут совершенно ни при чём. :rolleyes: