обнаружил, например, что у клеммников в чужих библиотеках неправильные диаметры под сверло

Где-то на ЛОРе была ветка о перепутанных выводах транзистора. Если не ошибаюсь, то именно в geda.

симулятор

У меня к ним стойкое отвращение после лаб в протеусе (игнорирует sleep) + в atmel studio с каждым обновлением чинится одно и отваливается другое. Нет, лучше уж макетка - там если и будут ошибки, то свои собственные, а не эмулятора.

Где-то на ЛОРе была ветка о перепутанных выводах транзистора. Если не ошибаюсь, то именно в geda.

Могут быть ошибки, но в стандартных библиотеках их, наверное, мало. А вот в сторонних может быть дофига. С транзисторами может быть проблема, когда у производителей разная нумерация. Вроде package одинаковый DPAK-2, а нумерация у одних 1-2-2-3, а у других 1-2-3-4, где 2 и 4 соединены между собой внутри. В стандартной библиотеке компонент DPAK-2 один, и автор символа мог не углядеть. Просто надо внимательнее.

У меня к ним стойкое отвращение после лаб в протеусе (игнорирует sleep) + в atmel studio с каждым обновлением чинится одно и отваливается другое. Нет, лучше уж макетка - там если и будут ошибки, то свои собственные, а не эмулятора.

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

Мне же гарантию надо дать. Эта же программа потом на сотне автоматов будет стоять, а люди в этот шкаф деньги кидают. А если глюки пойдут? Мне же отвечать :)

Ну а как ты отлаживаешь?

JTAG, debugWIRE + break points + logic analyzer

Неужели ты грузишь, смотришь, потом правишь и снова грузишь?

Выполняется средствами среды, незаметно для пользователя (т.е. отлаживаешь как в симуляторе, но на реальном устройстве)

протоколы внешние

word generator

на сотне автоматов будет стоять

а ты не проверил ее работу при граничных температурах, устойчивость к ЭМИ... ;)

JTAG, debugWIRE + break points + logic analyzer

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

word generator

Так симулятором пользуешься все же? Или что это? И может эта хрень смоделировать реальные процессы? Вот, например, у меня одновременно коммуникация с денежными аппаратами, одновременно с компом, одновременно работают внешние входы (энкодер клокает, например). Такие вот навороты тоже сможешь глянуть, нет ли коллизий? :)

а ты не проверил ее работу при граничных температурах, устойчивость к ЭМИ... ;)

Ну тут уж другие тесты совсем нужны. К программме они никакого отношения не имеют. У меня температуры нормальные. Автоматы только в помещениях будут стоять. Источники питания платы и всех двигателей раздельные. Но тем не менее я сейчас жалею об одной вещи, которую не сделал, - дополнительная защита по ESD входов контроллера. В процессе эксплуатации этой проблемы не будет, конечно, так как стационарная установка, никто туда не полезет, а вот при сборке на производстве может искрануть от руки. Может быть, вторую итерацию сделаю, чтобы все-таки защитку поставить - день работы. От греха подальше. От КЗ поставил, overcurrent protection есть, от перегрева тоже есть (в микросхемах уже), а это забыл. :)

что это? И может эта хрень смоделировать реальные процессы?

Железяка с МК, буферами и ЦАП, умеет тактироваться от внешних импульсов. Делает то же, что и пачка твоих симуляторов, но в реале.

Такие вот навороты тоже сможешь глянуть, нет ли коллизий?

Именно для этого он и нужен.

Железяка с МК, буферами и ЦАП, умеет тактироваться от внешних импульсов. Делает то же, что и пачка твоих симуляторов, но в реале.

Хех, у меня в реале вообще железяки нет. Этот аппарат - металлический шкаф, который два метра высотой, полтора шириной. Снял с него датчики на всякий случай и моторчик один захватил. Вот и все. :)

Да, ты обещал платку свою сфотать!

Именно для этого он и нужен.

Что делает этот word generator? Его можно программировать на спецификацию произвольного последовательного протокола какого-то устройства? Допустим, я хочу сделать так, чтобы word generator вел себя как master-устройство Modbus, чтобы он контрольную сумму по CRC16 считал, сам кадр формировал, сам таймауты все отмерял по спецификации (а в Modbus жесткие требования к таймаутам!), чтобы отвечал именно на те запросы, которые идут к устройству.

Не очень понятно. Понимаешь ли, я написал программу (симулятор), которая работает по спецификации протокола как внешние устройства, которая повторяет их функциональность (это три протокола). И я могу проверить соответствие реализаций протокола в плате спецификации и реакцию на ошибки в процессе реальной работы.

Например, я реально могу две операции провести нормально, сэмулировав поведение человека, который сует деньги, с паузами, а потом сделать так, что купюру «зажует» или связь нарушится или чт-то с датчиком произойдет. Просто программирую сценарий и прошел прогон симулятора. Это круто и удобно. :)

Что делает этот word generator?

Генерирует слова/отдельные импульсы в заданной пользователем последовательности как в цикле, так и в ответ на внешние воздействия.

я хочу сделать так

Делай, но тогда WG превратится в простую devboard (по окончанию эксперимента можно прошить «взад»; в обычном режиме прошивки не требует) однако задачу, возложенную на него, выполнит...

жесткие требования к таймаутам

... если хватит быстродействия (а даже если и не хватит - никто не мешает тактовать макетку Fosc/10)

программирую сценарий и прошел прогон симулятора

То же самое, но на железе.

фотографии

Пожалей мои интернеты! У нас тут сеть перегружена, ибо наводнение. Поэтому пока наслаждайся видом контроллера автотитратора... или не наслаждайся. Как допишу человеческий интерфейс к ПК - выложу в галерею на фоне установки.

. Поэтому я рванул искать - и вот нашел simavr. Только в Debian simavr не оказалось - я его сам опакетил. По simavr могу подсказать, если что.

В общем пишите на почту , если у Вас были какие заметки по ходу работы с simavr с удовольствием их почитаю... собственно все пытаюсь сделать статью чтобы народ слез уже с AVRstudio ... ну вот....

Вот потихоньку восстанавливаем материалы на сайте , авторство и источники конечно же укажу!

И да для Old_Hamster ,иногда тестовые примеры или DIY для себя хочется делать в свободных проектах, это показывает, что за некоторый код просить деньги уже бессмысленно.(пример Scilab и Salome)

А так с NX, COMSOL, Altium, IAR .... можно конечно, за ночь за две , делать.

Пожалей мои интернеты! У нас тут сеть перегружена, ибо наводнение. Поэтому пока наслаждайся видом контроллера автотитратора... или не наслаждайся. Как допишу человеческий интерфейс к ПК - выложу в галерею на фоне установки.

Хорошо, хорошо! Пожалею. Автотитратором насладился. :)

Генерирует слова/отдельные импульсы в заданной пользователем последовательности как в цикле, так и в ответ на внешние воздействия.

Ага, понятно. Ну то есть шибко много не умеет. Я же помню как-то давно, в 1999-м, я отлаживал в чем-то таком... забыл уже, чем пользовался. Это я делал MIDI-пульт, копию диджейского пульта Pioneer для нашего цифрового комплекса обработки звука (четвертый от конца абзац. Жаль фоток нет, только платы в PCAD остались на память). Ну, типа, подсовывал в нужные моменты что-то в регистры контроллера (как бы сработала кнопка или повернули галетник, или фейдер пошел вверх) и дальше гнал программу. И это было жутко неудобно, потому что надо постоянно что-то подсовывать без конца, чтобы смотреть, что происходит в программе. А в динамике вообще было нереал проверять.

То же самое, но на железе.

Это еще сложнее, чем программный симулятор.

В общем пишите на почту , если у Вас были какие заметки по ходу работы с simavr с удовольствием их почитаю... собственно все пытаюсь сделать статью чтобы народ слез уже с AVRstudio ... ну вот....

Когда разделаюсь с этими ребятами по этому проекту, то можно. Ну а если вдруг кто-то прямо сейчас начнет разбираться с simavr, то могу помочь.

Это еще сложнее, чем программный симулятор

Это дело привычки, личных предпочтений (один пишет скрипты для ПК, другой - код для МК) и доверия авторам симулятора. Немаловажную роль играет и среда разработки (вне студии я, скорее всего, не использовал бы отладку «в железе»).

Мужык! Спасибо, что ты есть и двигаешь СПО. Ты изложил разрабам gEDA проблемы?

Моделирование сильное, насколько я понял из написанного. Я обычно тестирую только важные части кода в виртуальном окружении. А то, что после hal только на живом МК.

Симуляция МК и моделирование его периферии, слишком много работы получается.

gEDA .... у вас эмулятор работает, после переноса на Qt4 ?

Я обычно тестирую только важные части кода в виртуальном окружении. А то, что после hal только на живом МК.

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

Симуляция МК и моделирование его периферии, слишком много работы получается.

В симуляторе самая сложная вещь - это сам микроконтроллер. Но эта работа уже выполнена - есть библиотека, которая его моделирует. А вот периферию не так уж и сложно писать по сравнению с микроконтроллером. А большая часть периферии вообще тривиально. Например, все, что работает как кнопка или простое бинарное срабатывание включено/выключено - это просто. Из более сложных моделей - это, например, мой лифт, который состоит из мотора, драйвера мотора, редуктора, энкодера (клоки по каналам A и B по таймеру в соответствии с угловой скоростью редуктора и направлением вращения) и концевиков. Я только с самого начала много времени потратил, так как разбирался со всем этим (документации, считай, нет), а потом прямо как по маслу пошло - копипаст своего же кода делаю.

А В примерах к симулятору даже симуляция дисплейчика HD77480 есть, матрицы светодиодов с графической демонстрацией программы часов и даже Arduino. А я еще протоколы написал, примеров для которых вообще нет - из исходного кода выуживал секреты.

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

Ты изложил разрабам gEDA проблемы?

Да они уже давно в курсе того, чего софт не умеет. С ними это обсуждают в рассылках. Сообщать нужно о багах или слать патчи. :)

Я про МК-шную периферию, с AVR конечно просто, там нет сложной периферии. А если МК cortex-m* или какой-то dsp. В идеале наверно по HDL надо симулировать, но его же никто не даст (и медленно было бы).

Внешние устройства, приводы, это ясно, что надо моделировать если задача в том, чтобы ими управлять. Выход я пока нахожу в том, чтобы где-то после hal ставить модель внешних устройств. Но получается отдельный режим моделирования, в котором не работает напрмиер rtos, нет отладочного cli т.к. код выполняется не на МК.

Не очень хорошо, но лучше идей нет, пока делаю так.

Я про МК-шную периферию, с AVR конечно просто, там нет сложной периферии. А если МК cortex-m* или какой-то dsp.

Вот, например, Android Emulator. Там-то уж не AVR. :)

А еще, когда это было модно, я использовал POSE (Palm OS Emulator), не имея реального устройства на руках. Использовалась связка Emacs (19-й или 20-й - не помню) под Wiidows + POSE + PRC-Tools. Отладка доступна, порт был доступен и даже пробрасывался на порт компьютера - можно было реальное железо подключать, что я и делал - подключал фискальный регистратор.

В идеале наверно по HDL надо симулировать, но его же никто не даст (и медленно было бы).

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

Наличие отладчика в любом IDE (для DSP, для МК) означает, что модель поведения процессора уже есть. Осталось только не ограничваться отладчиком, а сделать возможность программировать внешнюю среду для своих целей. А это как раз далеко не все делают.

Внешние устройства, приводы, это ясно, что надо моделировать если задача в том, чтобы ими управлять. Выход я пока нахожу в том, чтобы где-то после hal ставить модель внешних устройств. Но получается отдельный режим моделирования, в котором не работает напрмиер rtos, нет отладочного cli т.к. код выполняется не на МК.

М-м-м, а что значит, что не доступен отладочный cli? Отладчик? Если это имеется в виду, то доступен. У меня симулятор, если запустить с опцией -g, повисает на порту 1234 и ждет, когда avr-gdb к нему подключится, а дальше расставляешь точки останова и вперед.

Симуляция HDL гарантировала бы идентичность поведения (и багов) симулятора и реального МК.

А реализация модели периферии по информации из ДШ слишком времязатратное и невыгодное занятие.

Наличие отладчика в любом IDE (для DSP, для МК) означает, что модель
поведения процессора уже есть. Осталось только не ограничваться
отладчиком, а сделать возможность программировать внешнюю среду
для своих целей. А это как раз далеко не все делают.

Как это так? Отладчик это остановка выполнения по событиям и доступ к памяти, внутреннему состоянию. Если речь об отладке в симуляторе, то это моделирование а не отладка.

-м-м, а что значит, что не доступен отладочный cli?

У меня в своих устройствах обычно есть cli на одном из uart. Из него устройтсво можно конфигурировать, имитировать какие-то события, снимать телеметрию, и просто вызывать нужные куски кода с заданными параметрами. Но это все доступно только в реальном МК.

В модель код cli не включен по многим причинам. Хотя мне уже кажется, что можно его включить в модель если правильно организовать hal.

Отладкой с точками остановки как-то не привык пользоваться, особенно на МК.

Итого, я хотел сказать, что полная симуляция, вместе с МК и периферией (такой например как контроллер USB или SDIO), это может быть слишком тяжело.

Сам моделирую периферию следующим образом, для примера есть H-мост управляемый таймером. В коде есть hal функция hb_set_dc(float dc) устанавливающая заполнение. Все что внутри этой функции при моделировани не важно. Её параметр напрямую идет в модель, которая может даже не учитывать частоту а просто выставлять эквивалентное напряжение.

Симуляция HDL гарантировала бы идентичность поведения (и багов) симулятора и реального МК.

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

А реализация модели периферии по информации из ДШ слишком времязатратное и невыгодное занятие.

Да никакое оно не времязатратное. Ну нисколько вообще. Есть у тебя, предположим, внешний датчик, который выдает аналоговый сигнал в ADC. Какие проблемы? Напиши формулу преобразования, результат передай в симулятор МК. Это все, что нужно. Вообще не проблема ни разу.

У меня в своих устройствах обычно есть cli на одном из uart. Из него устройтсво можно конфигурировать, имитировать какие-то события, снимать телеметрию, и просто вызывать нужные куски кода с заданными параметрами. Но это все доступно только в реальном МК.

Опять не очень понимаю. Я еще раз опишу, как это работает у меня. Есть симулятор AVR - проект simavr. Это просто библиотека libsimavr.so, предоставляющая API, которое позволяет установить входное воздействие на любую ножку, получить событие, когда любая ножка изменила значение, получать события по обмену по USART и другие функции. Эта штука кушает реальную прошивку! Я пишу прошивку и гружу ее в этот симулятор. Он работает как реальный AVR, к которому можно просто программно прицепиться. Если мне нужно сделать простейшую вещь - сделать светодиодик, то я в программе (которая использует libsimavr.so) конфигурирую коллбэк, который вызывается, когда какая-то ножка (скажем, PE0) изменит значение. В процедуре я просто пишу «Зажегся светодиод на PE0\n» или могу его просто нарисовать, что он зажегся.

Когда внешние микросхемы, то просто ставлю коллбеки на все ножки, которые подсоединены к ним и получаю все события. Когда появляется комбинация по включению моторов, изменению направления, то я все это раппортую. Я вижу, что программа работает так, как я ее задумал. Если надо принимать какие-то события, то я пишу функции, которые у AVR управляют портами (все в API есть). А сценарии просто можно в main() симулятора даже делать. И я даже могу программно из симулятора внутрь МК залезть, чтобы происпектировать, а записалось ли значение в регистр, а как выставился какой-нибудь коэффициент деления и, если очень надо, могу просто подмахнуть снаружи любой регистр, если какая-то периферия у МК не реализована пока.

Твой cli через UART также будет работать в симуляторе, если он тебе будет нужен. Но с симулятором он тебе вообще не нужен. Просто тереметрию программно сделай в симуляторе. У меня так и прет телеметрия с временными отметками: что включилось, что выключилось, что получили деньгоприемники, что ответили, что спросил хост-компьютер, что ему ответило устройство. Никакие врезки в прошивку типа отладочного канала я вообще не далаю - прошивка такая, какая она будет в итоге.

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

Сам моделирую периферию следующим образом, для примера есть H-мост управляемый таймером. В коде есть hal функция hb_set_dc(float dc) устанавливающая заполнение. Все что внутри этой функции при моделировани не важно. Её параметр напрямую идет в модель, которая может даже не учитывать частоту а просто выставлять эквивалентное напряжение.

Не совсем понятно, но если я правильно понял, то именно об этом и идет речь. Что не надо никаких HDL. У тебя есть значение частоты, которое известно, что будет таким-то напряжением по формуле. Вот и преобразуй по ней. Вот именно так и работает.

Отладкой с точками остановки как-то не привык пользоваться, особенно на МК.

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

Как это так? Отладчик это остановка выполнения по событиям и доступ к памяти, внутреннему состоянию. Если речь об отладке в симуляторе, то это моделирование а не отладка.

Это и то, и другое. Модель с реальной (повторю) прошивкой с возможностью перехода в пошаговый режим исполнения как самой модели через обычный gdb, так и прошивки через avr-gdb.

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

Да никакое оно не времязатратное. Ну нисколько вообще. Есть у тебя,
предположим, внешний датчик, который выдает аналоговый сигнал в
ADC. Какие проблемы? Напиши формулу преобразования, результат
передай в симулятор МК. Это все, что нужно. Вообще не проблема ни
разу.

А в МК скажем ADC может быть сконфигурирован делать выборки сериями в разных порядках или параллельно, по событиям от таймеров, с передачей результата через DMA. Как тогда соединить напряжение на ноге с кодом прошива?

Здесь явно хочется избавиться от этого уровня при моделировании. И отправлять результат из внешнего кода в МК-код напрямую. Но это и получается отдельная версия прошива для моделирования. В моем случае она и вовсе собирается под x86 и только частично.

Если упрятать все что можно за hal, то может быть удастся сделать более глубокое моделирование. Буду делать.

А в МК скажем ADC может быть сконфигурирован делать выборки сериями в разных порядках или параллельно, по событиям от таймеров, с передачей результата через DMA. Как тогда соединить напряжение на ноге с кодом прошива?

Тебе только надо постоянно вычилять новое значение на ножке по глобальному времени (у тебя же какая-то функция сигнала есть?). Чтобы быть более точным, скажу про simavr. Для этого в любой момент времени ты на нужные входы ADC (или на все вообще) записываешь новое значение входной величины в милливольтах в зависимости от глобального времени. Для этого используются прерывания (это не прерывания AVR - это внутренние прерывания симулятора!): ADC_IRQ_ADC<n>, где <n> - номер канала. В программе это будет выглядеть примерно так:

#include <simavr/avr_adc.h>

...
avr_raise_irq(analog_inputs->irq + ADC_IRQ_ADC0, func0(t));
avr_raise_irq(analog_inputs->irq + ADC_IRQ_ADC1, func1(t));
avr_raise_irq(analog_inputs->irq + ADC_IRQ_ADC2, func2(t));
avr_raise_irq(analog_inputs->irq + ADC_IRQ_ADC3, func3(t));
avr_raise_irq(analog_inputs->irq + ADC_IRQ_ADC4, func4(t));
avr_raise_irq(analog_inputs->irq + ADC_IRQ_ADC5, func5(t));
avr_raise_irq(analog_inputs->irq + ADC_IRQ_ADC6, func6(t));
avr_raise_irq(analog_inputs->irq + ADC_IRQ_ADC7, func7(t));
...

Структура analog_inputs - твоя. Нукак бы это гипотетические твои аналоговые входы. Ее инициализация тут пропущена. func<n> - это твои функции. В общем-то, и все. А симулятор в цикле крутится и таймеры у него все работают и заберут нужные значения с нужных каналов в соответсвии с прошивкой.

UPD: Прерывания симулятора - это и есть способ с ним взаимодействовать. Если произошло внешнее событие на порту, то он тебе выставит прерывание и у тебя обработчик notify стоит. Если ты хочешь ему что-то передать. то ты выставляешь прерывание - он словит.

А не пробовали kiCAD? Пользуюсь... Вроде бы нормально работает

А не пробовали kiCAD? Пользуюсь... Вроде бы нормально работает

Так и PCB вроде бы нормально работает. А KiCAD я тыкал палочкой в 2006-м, по-моему, но остался на gEDA. У меня в то время в gEDA наработки были и свои библиотеки. Я тогда убедился в корректности экспорта в GERBER в gEDA, поэтому посчитал, что лучше от греха подальше. Не готов был ко встрече с новыми глюками и переделкой всего. Переправа и кони.

Единственный вопрос, который я выясню, какие преимущества у KiCAD есть при ручной трассировке, то есть какие есть интеллектуальные средства облегчения этого процесса и есть ли смысл что-то перенести в gEDA. Может быть, уже в gEDA что-то появилось. Я пока пользуюсь Debian oldstable и gEDA оттуда же.

Скажите, а вы только разрабатываете или еще и изготавливаете печатные платы? И если изготавливаете, то как печатаете?

Скажите, а вы только разрабатываете или еще и изготавливаете печатные платы? И если изготавливаете, то как печатаете?

Это я дома все делаю, а не в какой-то компании. :) Эти платы я заказывал на производстве печатных плат. Дал им файлы Gerber, а также сверловки, соответствующие их требованиям, дал сопроводительный текст. Они сделали.

А если не на производстве делаю, то ЛУТом, но это очень редко.

В производство отдавать не так и много док надо: гербера для изготовления плат, сборочник со списком компонентов. Или что-то еще у вас? А месяц нормальный срок для проекта, по ходу реализации грабли выходят. Я часто еще и макет сам собираю, прежде чем платы в печать отправить. Очень приятно видеть такую работу на ЛОРе. P.S. AVR - кака :)

Я довольно часто делаю что-либо руками. Печать плат заказываю у человека. Работа получается кустарная и не всегда высокого качества. В связи с этим всерьез задумался о покупке halk2020 или его более дорогого брата. Как вы думаете, разумное ли это решение?

Ъ

Круто!

В производство отдавать не так и много док надо: гербера для изготовления плат, сборочник со списком компонентов. Или что-то еще у вас?

Для производителя фактически все. Если монтаж только не осуществлять у контрактника. Для монтажа надо сборочный хоть какой-то, спецификацию. Если там есть робот, то им можно еще файл pick-and-place (он же xy-файл) с координатами центроидов компонентов. Но оборудование у контрактора позволяет обучить его вручную оператором. Робот запоминает, что и где стоит, а потом тупо повторяет. Некоторые не GERBER просят, а прямо САПР-овский файл, а там уже сами уже всю информацию получают для своих нужд.

Я довольно часто делаю что-либо руками. Печать плат заказываю у человека. Работа получается кустарная и не всегда высокого качества. В связи с этим всерьез задумался о покупке halk2020 или его более дорогого брата. Как вы думаете, разумное ли это решение?

Откровенно говоря, я ничего не знаю про этот агрегат, сорри. НАверное, надо истории успеха поискать и видео, да поглядеть, что аппарат может. Если честно, то я скептично смотрю на фрезерование. Какой класс точности halk позволит делать? Да и плата не менее кустарно будет вглядеть.

Я думаю так. Если ты делаешь для себя, то какая разница, как выглядит - кустарно или нет? А если не для себя, а для кого-то, и надо, чтобы было красиво, то лучше на производстве заказать. ИМХО, ЛУТ или фоторезист проще. Надо только технологию для себя отработать (бумажку подобрать, режимы нагрева, травления).