![](https://electronix.ru/forum/uploads/set_resources_23/84c1e40ea0e759e3f1505eb1788ddf3c_pattern.png)
![](https://electronix.ru/forum/uploads/set_resources_23/84c1e40ea0e759e3f1505eb1788ddf3c_default_photo.png)
hw_engineer
Участник-
Постов
43 -
Зарегистрирован
-
Посещение
Репутация
0 ОбычныйИнформация о hw_engineer
-
Звание
Участник
Посетители профиля
1 071 просмотр профиля
-
дубль, на всякий... TestPrj.zip
-
avr-gcc + debian11 + "stack smashing detected"
hw_engineer ответил hw_engineer тема в AVR
о, спасибо, буду знать! т.е. 100 мало? -
По ч.5 - самое интересное. Цель близка - нужно для примера накидать схемку, компоненты на плату, расставить их... Короче - см. TestPrj.zip. Дисклеймер: проект не имеет какой-либо практической значимости, возможно содержит ошибки, создан только с целью демонстрации способа получения чертежей и BOM. Строго говоря, я планировал компоненты расставить с помощью "Automatically Place Off-Board Footprints", но узрев результат, не выдержал и раскидал некоторые мелочи поаккруатнее, но без соблюдения назначения. Итак, BOM. Он создаётся с помощью kicad_BOM.py (сделал из комплектного), который тоже есть в архиве: нужно "добавить новый плагин", выбрать скрипт и сгенерировать BOM. Есть тонкости: - к kicad_BOM.py прилагается kicad_netlist_reader.py, который пришлось немного допилить; - BOM генерится в 2 этапа: -- сначала генерится xml без помощи скрипта; -- из xml скрипт генерит то что требуется, причём: --- если не указывать опции, то по умолчанию генерится FULL - не факт что соберётся, специально поставил пару компонентов друг на друга ;) --- можно перегенерить новый BOM из консоли с указанием опций, в данном "проекте" список опций можно увидеть с помощью "Edit symbol fields" - "Option": окманда генерации "BOM с RS232, 6-пин разъёмом и кварцем" будет такой: kicad_BOM.py TestPrj.xml TestPrj.csv RS232,RS6pin,XTAL --- список опций будет указан в шапке BOM; -- компоненты сливаются в одну строку по PartNumber (в примере это клеммники; наличие же "*diff*" в поле Value резисторов и т.п. должно насторожить и инициировать перепроверку - где-то допущено несоответствие); -- при генерации BOM будет выведен список исключённых компонентов, как в консоль, так и в файл excluded_components.lst. Теперь плата. Чертёж: после минимальной расстановки %R и %V, а именно: - поворот; - перенос на удобную сторону от компонента сторону (например поставить все %R сверху или слева); плата уже готова к выоду чертежа: - File->Print; - выбрать 2 слоя: Edge.Cuts и F.Fab; - чекнуть "All layers on a single page"; - настроить остальное по вкусу; - напечатать (см. pdf в архивчике) и радоваться; - обратить внимание, что аккуратно и без выносок расставить Ref в шелкографии в данном случае не удастся - и радоваться ещё больше. Для монтажников уже нормально, но для аккуратного, а главное нормально образмеренного чертежа нужно вывести слои F.Fab и/или B.Fab в dxf и уже в редакторе чертежей довести до ума. POS-файлы: - сгенерировать POS как обычно; - запустить скрипт kicad_CleanPOS.py например так: kicad_CleanPOS.py excluded_components.lst TestPrj-top.pos res_TestPrj-top.pos - из POS-файла будут удалены все "ненужные" компоненты. Вроде всё.
-
По ч.3 - FP либы Есть ещё одна цель, про которую забыл сказать - получение вменяемых чертежей с минимальными усилиями. Подцель этой цели - указывать Ref мелких компонентов только на чертеже, т.к. Ref на плате в слое шелкухи порой занимает места больше чем сам компонент, т.к. шелко-буковки высотой менее 0.7мм почти нечитаемы (0.5мм - можно отличить "GND" от "PWR" и только). - Список библиотек. Мне пока что хватает такого набора: - (Case_part) - корпусные элементы, которые имеет смысл отобразить на плате в явном виде: радиаторы, детали корпуса, держатели светодиодов... - (PCB_part) - элементы платы: тестпойнты, логотипы, монтажные отверстия... - ElectroMech - реле, кнопки, разъёмы... - non-standard - тут всё то, что так или иначе отступает от рекомендаций, например, LQFP-100 для толстой фольги. - discrete - тут те самые, с нумерацией выводов буковками - package - стандартные и "фирменные" микросхемные корпуса - passive - стандартные и "фирменные" корпуса пассивки - Названия и поля. -- "фирменные" токовые шунты 2512 заметно отличаются конструкцией от стандартного 2512, поэтому появляется "фирменный" FP с названием а-ля "[Bourns]CRE2512-FZ-R001"; -- хорошо бы заполнить "Descripton" разумным образом, например "2512/6432 High Power Current Sense Chip Resistor, 1...4mOhm"; -- в названии элемента, чем-то отличающегося от стандартного, добавляем после "^" пояснение, например "CR0805^hidens", "SOIC-8_3.9x4.9_p1.27^1fet", "SOD523^np" (неполярный то бишь); -- необходимо(!) добавить доп.поля "%R" и "%V" в слое F.Fab, причём размером хоть 0,3мм - в итоге это попадёт в pdf-файл с хорошим разрешением и будет читаем; -- размещать "%V и %R" нужно с прицелом на будущие чертежи: у крупных компонентов типа SOIC - внутри корпуса, у мелких - рядом с изображением корпуса (а что, кто-то ещё не делает чертёж корпуса элемента в слое F.Fab?! далааадна...) - Конструкция. Как правильно сделать FP - долго формализовывать, люди на этом деньги зарабатывают :) Но всё же: - чертёж корпуса в слое F.Fab - обязательно, причём не формальный размер, а максимальный, с допусками; - F.CrtYd - для SMD обязательно, для THD ОЧЕНЬ желательно, кроме разве что элементов, которые: -- не прилегают к плате плотно - электролит лёжа, светодиод стоя; -- выступают за габариты платы - разъёмы всякие, те же светодиоды; - площадки - лучше с закруглениями, рекомендуемые по умолчанию 25% я поправляю на 10-15%, но не менее 0,1мм; - пасту на больших площадках разбить с помощью "Pad type"="SMD aperture" - тоже со скруглениями.
-
Есть несколько мыслей по ведению личных библиотек. Может быть интересно тем, кто не накопил своих либ, но задумывается об этом. А может и ещё кому пригодится. Итак. Библиотеки состоят не только из кучи lib и kicad_mod, библиотеки это: 1. набор lib 2. набор pdf и dcm (опционально, но полезно) 3. набор kicad_mod 4. набор wrl и step (опционально, но полезно) 5. набор скриптов по формированию файлов для производства (собственно, это самое для меня важное!) На выходе проекта должны быть сформированы переменные данные: - BOM-лист по правилам: -- с учётом опций установки компонентов; -- группировка по PartNumber без учёта Value (!) /*например, я называю кнопки по их функции => в стандартный БОМ каждая кнопка занимает отдельную строку*/ - POS-файл(-ы), откуда удалено то, что не требуется устанавливать в данной опции(-ях). Для начала - по символьным либам (ч.1). - Наименования -- символы ()[]^ являются разрешёнными в именах, и они никогда не употребляются производителями в PartNumber компонентов; -- всё что в круглых скобках отображается вверху списков, поэтому: --- особые библиотеки заключать в круглые скобки, например, особая библиотека (PCB_part) - в ней содержится то, что есть на схеме и на плате, но является частью платы (лого, тестпойнты, реперы и т.д.) - все компоненты из этой библиотеки будут выкинуты из BOM; --- обобщённые компоненты заключать в двойные круглые скобки, например ((ZQ)), ((VD_DIODE)), ((VD_SCHOTTKY)); --- шаблонные компоненты заключать в одиночные круглые скобки, например (SMAJxxxA); -- всё что в квадратных скобках, отображается внизу списков, поэтому: --- "фирменные" библиотеки называть примерно так: [STM], [IR], но лучше не надо заводить "фирменных" либ - это в итоге неудобно /*лично мне оказалось*/; --- "фирменные" компоненты начинать с названия производителя, заключённого в квадратные скобки, например [LITE-ON]LTV356T. - Особая библиотека - discrete -- проблема: есть один стандартный символ FET, но ему может соответствовать несколько разных FP с разной нумерацией выводов, например: sot23, to252 и so8 в двух вариантах; -- в нумерации выводов FP допускается НЕ использовать собственно числа, т.е. можно "пронумеровать" выводы буквами, а в названии этого FP нужно добавить доп.информацию после "^", например: SOIC-8_3.9x4.9_p1.27^1fet (об этом ч.3); -- примеры "нумерации" выводов: --- диоды: A и C (с ОА: A C1 C2 и т.д.) --- FET: S G D, S1 S2 G1 G2 D1 D2 --- BJT: B E C --- симистор: A1 A2 G --- оптрон: LED_A LED_C BJT_E BJT_С -- чтобы не путаться в "обычных" компонентах и "со странной нумерацией выводов" я скинул все "странные" в библиотеку discrete /*может и зря*/; -- "хитрые" компоненты, типа оптронов с доп.выводами можно классифицировать как обычные компоненты. - Поля элементов -- "Description" хорошо бы заполнять как-то разумно, например, начинать с типа элемента, "Diode, описание", "OpAmp, описание", "2xFET, описание" ("описание" - не напряжения-токи, "Description" должно быть что-то типа "Diode, Small signal Schottky diode") -- закупцам обычно НИЧЕГО не говорит "конденсатор 0,1мкФ 25В 0603" - они требуют "как это называется и где это купить": добавляем поля элементов "Manufacturer" и "PartNumber", которые можно заполнить полностью, "заготовками" для шаблонных компонентов или оставить пустыми для обобщённых компонентов (автозаполнение PartNumber по Ref+Footprint+Features хотя бы для C и R - моя отдалённая мечта, а пока заполнение этих полей зависит от аккуратности лично моей); -- часто требуется доп.информация по компоненту "вотпрямщас" - без инета и открывания файлов: добавляем поле "Features", где можно указать всё что душе угодно, например "55V 31A 60mΩ 2..4V" (это про IRF5305) - это также попадёт в BOM и будет служить доп.источником инфы "есличто", т.к. CL31B105KCHNNNE ещё поди пойми что значит; -- можно завести отдельные поля, с любыми (в т.ч. кириллицей) названиями кроме "Option", "Manufacturer", "PartNumber", "Note", "Replacement" и заполнить их на угодно, например "Напряжение"="25В", "Диэлектрик"="X7R", "Допуск"="10%" и т.д. - они в итоге будут слиты в поле "Features" и попадут в BOM (об этом ч.5); -- как правило, проект не состоит из монолитного "паятьффсё!", обычно подразумеваются какие-то опции: что-то ставим, что-то убираем, но если не ставим X, то ставить Y не имеет смысла и т.д., поэтому заводим поле "Option" (лучше не в либах заводить, а добавлять в схеме по мере необходимости); -- в схеме: --- поле "Option" заполнять по правилам python, например "(o1|o8)&(o3|o6|o5)&o9" или просто "option2", названия опций = латиница+цифры+"_"+фантазия; --- в поле "Value" ставить "n.c." "NU" и т.д. только если действительно компонент поставлен на всякий пожарный и не будет устанавливаться ни в одной из опций, у остальных компонентов "Value" должны быть заполнены нормально - "10k", "0.1uF" и т.д. - независимо от опций. Основные моменты по lib изложил, продолжу как будет время и/или интерес :)
-
+1 аргумент в пользу "своих": если линия набивки автоматизированная, то нужно делать под линию, т.к. выводы могут быть загнуты на практически любых расстояниях (т.е. шаг выводов == параметр линии автонабивки, а не типа резистора). PS: vervs опередил :)
-
Для "боевого" варианта (стальной трафарет) - закруглённые. Для "чистапапробовать" (ПЭТФ или из чего там режут одноразовые трафареты на плоттере) - желательно сплошь квадратиками. "Боевой" вариант либо плохо режется, либо вообще не режется на плоттере => как-то надо получить прямоугольники из платы, где все компоненты со скруглёнными КП. Больше причин нет.СПГС в скруглённых площадках тоже включать не надо :)
-
из закруглённых окошек в трафарете для паяльной пасты эта самая паста легче и чище вываливается.
-
см. предыдущую страницу
-
Скрипт для "оквадрачивания" всех окон паяльной маски на плате: -- собственно окон от КП со скруглением -- "нарисованных" прямоугольниками с width>0 -- "нарисованных" линиями с width >0 Ограничения: -- паста вне футпринтов игнорируется, -- в ФП линии и прямоугольники должны быть ориентированы под углами 0 или 90. Чую, можно сделать изящнее, но пока не разобрался. Результат выглядит примерно так: kicad_BoxPaste.py
-
Забавный глюк в "платнике": в режиме Flip Board View полигоны не выбираются кликом мышки, тыкал минут 5, пока не дошло :) Если кликнуть-и-поятнуть - выбирается всё, в т.ч. и все попавшиеся в зону полигоны. Version: 5.1.9+dfsg1-1, release build Libraries: wxWidgets 3.0.5 libcurl/7.74.0 OpenSSL/1.1.1k zlib/1.2.11 brotli/1.0.9 libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.43.0 librtmp/2.3 Platform: Linux 5.10.0-9-amd64 x86_64, 64 bit, Little endian, wxGTK Build Info: wxWidgets: 3.0.5 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.24 Boost: 1.74.0 OpenCASCADE Technology: 7.5.0 Curl: 7.72.0 Compiler: GCC 10.2.1 with C++ ABI 1014
-
avr-gcc + debian11 + "stack smashing detected"
hw_engineer ответил hw_engineer тема в AVR
Вроде бы пара опций после -Wl это штатный режим (до сих пор работало, по кр.мере), но на всякий случай попробовал и отдельно: avr-gcc -c -mmcu=atmega64 -I. -gstabs -Os -Wall -Wstrict-prototypes -std=gnu99 main.c -o main.o avr-gcc -mmcu=atmega64 -I. -gstabs -Os -Wall -Wstrict-prototypes -std=gnu99 main.o --output main.elf -Wl,-Map=main.map -Wl,--cref -lm collect2: fatal error: ld terminated with signal 6 [Аварийный останов] compilation terminated. *** stack smashing detected ***: terminated make: *** [makefile_new:221: main.elf] Ошибка 1 -
avr-gcc + debian11 + "stack smashing detected"
hw_engineer ответил hw_engineer тема в AVR
После долгих раздумий выяснилось, что линковщик перестал адекватно реагировать на -Wl,-Map=atmega64.map,--cref что, вообще-то, неожиданно... Проблема, как я понимаю. не в проекте, а в системе, питоновских скриптах, что ли. Если "карта" не требуется, то elf/hex собираются нормально. -
avr-gcc + debian11 + "stack smashing detected"
hw_engineer опубликовал тема в AVR
Добрый день. После перерыва в программировании минимум в полгода потребовалось пересобрать гарантированно рабочий makefile-based проект avr, вылезает ошибка *** stack smashing detected ***: terminated При этом при сборке пустого проекта ошибка ровно та же самая: $ cat ./main.c int main (void) { return 0; } $ make -------- begin -------- avr-gcc (GCC) 5.4.0 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiling: main.c avr-gcc -c -mmcu=atmega64 -I. -gstabs -DF_CPU=SYSTEM_CLOCK -Os -Wall -Wstrict-prototypes -Wa,-adhlns=main.lst -std=gnu99 main.c -o main.o Linking: atmega64.elf avr-gcc -mmcu=atmega64 -I. -gstabs -DF_CPU=SYSTEM_CLOCK -Os -Wall -Wstrict-prototypes -Wa,-adhlns=main.o -std=gnu99 main.o --output atmega64.elf -Wl,-Map=atmega64.map,--cref -lm collect2: fatal error: ld terminated with signal 6 [Аварийный останов] compilation terminated. *** stack smashing detected ***: terminated make: *** [makefile:391: atmega64.elf] Ошибка 1 В августе обновился деб10->деб11. Подскажите, кто может, что изменилось и куда копать? PS проекты под STM32 пересобираются нормально. -
"На третий день Зоркий Сокол заметил" такой косяк с компонентами и полигонами: 1) ставлю на плату компоненты (все КП по умолчанию в части термо-барьеров - "как у родителя") 2) натягиваю полигон с термо-барьерами - заливается всё правильно 3) у одного из компонентов (не принципиально какого) меняю свойства ВСЕГО КОМПОНЕНТА на "соединение с зоной - solid" - заливается опять же правильно, без ТБ 4) далее у того же компонента меняю свойства обратно - и вот тут полигон заливается НЕПРАВИЛЬНО (точнее, неожиданно), а именно - как solid Причина в том, что смена свойства компонента необратимо (в том смысле что вернуть свойства можно либо ручками, либо обновив компонент из либы) меняет свойства КП в нём с "как у родителя" на "solid", что, какмнекаацца, неправильно.