בקרת גרסאות לחומרת קוד פתוח: 10 שלבים

2024 מְחַבֵּר: John Day | [email protected]. שונה לאחרונה: 2024-01-30 09:16

לצוות ב- Brainbow יש מספר פרויקטים של אלקטרוניקה מתחת לחגורות שלנו, ורצינו לשתף אתכם בתהליך השימוש שלנו בבקרת גרסאות לניהול תהליך העבודה שלנו בעיצוב אלקטרוניקה. זרימת עבודה זו שימשה לפרויקטים גדולים וקטנים, מלוחות פשוטים של 2 שכבות ועד מורכבות של 10 שכבות, ומבוססת על כלי קוד פתוח. יש לקוות שאחרים יוכלו לאמץ לעצמם את תהליך העבודה שלנו ולהרוויח את היתרונות של בקרת גרסאות לפרויקטים משלהם. אך אילו יתרונות יכולה בקרת הגרסאות להציע פרויקט אלקטרוניקה?

שלב 1: מדוע בקרת גרסאות האלקטרוניקה שלך?

בקרת גרסאות (aka בקרת מקור או בקרת גרסה) היא תפיסה מובנת ומאומצת בהנדסת תוכנה. הרעיון מאחורי בקרת המקור הוא מעקב שיטתי שנעשה בקוד המקור של תוכנית או יישום. אם שינויים שוברים את היישום, תוכל להחזיר את קבצי קוד המקור למצב עבודה ידוע מהעבר. בפועל, מערכות בקרת מקורות מאפשרות לך לעקוב אחר ההיסטוריה של אוסף קבצים (בדרך כלל קבצי קוד המקור של תוכנת מחשב, אתר וכו '), ולדמיין ולנהל שינויים בקבצים אלה.

מעקב אחר היסטוריית השינויים בפרויקט נראה שימושי לפרויקטים של אלקטרוניקה; אם אתה טועה במערכת המעגלים, או משתמש בטביעת הרגל הלא נכונה של פריסת ה- PCB, יהיה נחמד לעקוב אחר אילו טעויות ואילו תיקונים יושמו בשינויים שונים בפרויקט. זה יהיה שימושי גם ליצרנים אחרים לראות את ההיסטוריה הזו ולהבין את ההקשר ואת המניעים של שינויים שונים.

שלב 2: הכלים: KiCad ו- Git

אנו משתמשים בפרויקט זה בשני כלים עיקריים: מערכת בקרת הגרסאות (VCS) ותוכנית אוטומציה לעיצוב אלקטרוניקה (EDA או ECAD).

ישנן מערכות בקרת גרסאות רבות, אך אנו משתמשים ב- GCS המופץ של VCS. אנו משתמשים בו מכמה סיבות, אך המפתח הוא שזה קוד פתוח (צ'ק!), קל לשימוש (צ'ק!) ו- VCS הסטנדרטי דה-פקטו לתוכנות קוד פתוח (בדוק!). אנו נשתמש ב- Git כ- VCS כדי לעקוב אחר השינויים בקבצים בהם תוכנית ECAD שלנו משתמשת. הוראה זו אינה דורשת היכרות עם Git, אך יש להניח נוחות כללית באמצעות שורת הפקודה. אנסה לקשר למשאבים מועילים לשימוש הן ב- Git והן בשורת הפקודה לפי הצורך.

רוב מערכות בקרת המקורות פועלות טוב במיוחד עבור קבצים מבוססי טקסט, כך שתוכנית ECAD המשתמשת בקבצי טקסט תהיה מצוינת. היכנסו ל- KiCad, קוד הפתוח "חבילת הפלטפורמות והקוד הפתוח אלקטרוניקה לעיצוב אוטומציה" המגובה על ידי חוקרים ב- CERN. KiCad הוא גם בעל קוד פתוח (צ'ק!), קל לשימוש (אם כי חלק לא יסכימו איתי לגבי זה), ומסוגל מאוד לעבודות מתקדמות בעיצוב אלקטרוניקה.

שלב 3: התקנה

כדי להתקין תוכניות אלה, עקוב אחר ההוראות מאתרי ההורדות השונים המקושרים להלן.

• KiCad הוא חוצה פלטפורמות (ובאופן מסחרר; דף ההורדות שלהם מפרט 13 מערכות הפעלה נתמכות ומציע הורדת קוד מקור אם אף אחת מהן לא מתאימה לך). השתמש בהתקנת ברירת המחדל המאושרת של kicad, לא במבנה הפיתוח הלילי. עיין בשלב 4 לפרטים אופציונאליים מתקדמים בנושא התקנת הספרייה.
• Git הוא גם חוצה פלטפורמות. אם אתה משתמש ב- Windows, הייתי ממליץ על פרויקט Git עבור Windows המרשים לחוויה שימושית יותר ומצוידת במלואה.

תיעוד ההתקנה הזמין בשני האתרים הללו יהיה שלם יותר מכל תיאור שאני יכול להציע כאן. לאחר הורדת והתקנת שתי התוכניות, תוכל לשכפל את תבנית הפרויקט של בריינבו ממאגר Github שלנו. הפקודה gon clone לוקחת את המבנה `gon clone {src directory} {target directory}`; עבור הפרויקט שלנו, השתמש ב- `git clone https://github.com/builtbybrainbow/kicad-starter.git {target directory}`.

שיבוט git repo הוא צורת העתקה מיוחדת; כאשר אתה משבט פרויקט, אתה מקבל עותק של כל הקבצים הכלולים במאגר, כמו גם את כל ההיסטוריה של פרוייקט במעקב Git. על ידי שיבוט המאגר שלנו, אתה מקבל ספריית פרויקטים שכבר בנויה עם ההמלצות שלנו לשימוש ב- Git עם KiCad. נעסוק יותר במבנה הפרויקט בשלב 6, או שתוכל לדלג לשלב 7 אם אתה מגרד להתחיל לעבוד.

כמה משימות משק בית מהירות - הפעל את 'git remote rm origin' כדי להסיר את הקישור לפרויקט Github שממנו משובטים. כמו כן, הפעל `git commit --amend --author =" John Doe "`, והחלף את פרמטר המחבר בשם שלך ובאימייל שלך. זה מתקן את ההתחייבות האחרונה (שבמקרה זה היא גם ההתחייבות הראשונה) ומשנה את המחבר אליך, ולא בריינבו.

שלב 4: הערת התקנה: ספריות KiCad

הערה מהירה אחת על מבנה הספרייה של KiCad. KiCad מספקת מערך ספריות המתוחזק על ידי צוות המפתחים למגוון רחב של רכיבים חשמליים. יש שלוש ספריות עיקריות:

• סמלים סכמטיים: סמלים המשמשים לייצוג רכיבים אלקטרוניים בשרטוט סכמטי של מעגלים.
• עקבות PCB: רישומי 2D המייצגים את טביעת הרגל בפועל (כריות נחושת, טקסט על מסך משי וכו ') שישמשו בעת פריסת המעגל על לוח PCB.
• דגמי תלת מימד: דגמי תלת מימד של רכיבים אלקטרוניים.

ספריות אלה יורדות יחד עם חבילת התוכניות KiCad שהתקנת זה עתה. אתה יכול להשתמש ב- KiCad ללא כל מאמץ נוסף. עם זאת, עבור "משתמשי כוח", קבצי המקור של הספריות מאוחסנים במאגר git ב- Github, ומאפשרים למשתמשים שרוצים להישאר מעודכנים בשינויים האחרונים לשכפל את ריפויי הספרייה למחשב משלהם. למעקב אחר הספריות עם git יש מספר יתרונות - אתה יכול לבחור מתי ברצונך לעדכן את הספריות שלך, ועדכונים צריכים רק לשלב שינויים בקבצים, במקום להוריד שוב את כל קבצי הספרייה. עם זאת, אתה אחראי לעדכון הספריות, אשר קל לשכוח ממנה.

אם ברצונך לשבט את הספריות, אתר זה מפרט את הצעות השונות של Github KiCad. Git שיבוט את הספריות למחשב שלך (למשל: `git clone https:// github.com/KiCad/kicad-symbols.git`), ולאחר מכן פתח את KiCad, בחר בסרגל התפריטים" העדפות "ולחץ על" הגדר נתיבים … ". זה מאפשר לך לספר ל- KiCad את נתיב הספרייה שאליו תחפש כל ספרייה. משתני סביבה אלה הם ברירת מחדל לנתיב לספריות המותקנות בהתקנת KiCad; שמתי לב לערכים אלה כדי שאוכל לחזור לספריות ברירת המחדל במידת הצורך. הנתיב KICAD_SYMBOL_DIR אמור להפנות לספריית הסימניות של המשובטים שלך, ל- KISYSMOD לספריית המשובטים של kicad-footprints ול- KISYS3DMOD לספריית המשובטים kicad-packages3d.

כאשר ברצונך לעדכן את הספריות, תוכל להריץ פקודה פשוטה של 'git pull' במאגר הספרייה שתגיד ל- Git לבדוק אם יש הבדלים בין העותק המקומי של ריפו הספרייה לבין ריפו 'מרוחק' של Github, ולעדכן אוטומטית את עותק מקומי לשילוב שינויים.

שלב 5: יסודות Git

Git היא תוכנית מורכבת ורבת פנים, עם ספרים שלמים המוקדשים לשליטה בה. עם זאת, ישנם כמה מושגים פשוטים שיעזרו לך להבין כיצד אנו משתמשים ב- Git בזרימת העבודה שלנו.

Git עוקב אחר שינויים בקבצים באמצעות סדרה של שלבים. שינויים רגילים מתרחשים בספריית העבודה. כאשר אתה שבע רצון מהשינויים שביצעת בסדרת קבצים, אתה מוסיף את הקבצים ששינית לאזור הבמה. לאחר שביצעת את כל השינויים שאתה מתכנן וערמת את כל הקבצים שתרצה לעקוב אחריהם ב- Git, אתה מחייב את השינויים האלה למאגר. התחייבויות הן בעצם תצלומי מצב של הקבצים במאגר בזמן מסוים. מכיוון ש- Git עוקב אחר שינויים בקבצים ושומר שינויים אלה בהתחייבות, בכל שלב תוכל להחזיר פרוייקט למצב בו הוא נמצא בכל התחייבות קודמת.

ישנם נושאים מורכבים יותר, כמו הסתעפות ושלטים, אך איננו צריכים להשתמש בהם כדי להשיג את היתרונות של שליטה במקורות. כל מה שאנחנו צריכים זה לעקוב אחר שינויים בקבצי העיצוב של KiCad שלנו עם סדרה של התחייבויות.

שלב 6: מבנה הפרויקט של KiCad

הבה נבחן מקרוב את מבנה פרויקט KiCad-Starter ששבטת קודם לכן. הוא מחולק למספר ספריות משנה לארגון קל:

• מעגל: תיקיה זו מכילה את קובצי הפרויקטים של KiCad בפועל (סכמטי, PCB וכו '). אני לא משנה את שם התיקיה הזו, אבל אני משנה את שם הקבצים בפנים בשם הפרויקט (Circuit.pro => ArduinoMini.pro).

  • Circuit.pro: קובץ הפרויקט KiCad
  • Circuit.sch: הקובץ הסכימטי של KiCad.
  • Circuit.kicad_pcb: קובץ הפריסה של KiCad PCB.
• תיעוד: תיקיה זו מיועדת לאחסון תיעוד בנוגע לפרויקט. יש לנו תוכניות לשיפור שטח זה בעתיד, אך לעת עתה הוא מכיל קובץ README פשוט. השתמש בו כדי לאחסן הערות על הפרויקט לעתיד שתסקור.
• ייצור: תיקיה זו היא המקום שבו תוכל לאחסן את קבצי הגרבר שבהם ישתמשו רוב בתי האב לייצור הלוח שלך. אנו משתמשים בו גם לאחסון קבצי BOM ומסמכים אחרים שעשויים להיות נחוצים לייצור והרכבה.
• ספריות: תיקיה זו מיועדת לאחסון קבצי ספרייה ספציפיים לפרויקטים (נסקור זאת עוד בכמה שלבים).

ייתכן שגם שמת לב לכמה קבצים אחרים (במיוחד אם אתה 'ls -a' הספרייה). ספריית.git היא המקום שבו Git עושה את הקסם שלו, ושומר את ההיסטוריה של המאגר. קובץ.gitignore משמש כדי לספר ל- Git מאיזה קבצים עליו להתעלם ולא לאחסן אותו בבקרת מקור. לרוב מדובר בקבצי גיבוי ש- KiCad מייצר, או בכמה קבצים "שנוצרים" שונים, כמו רשימות רשתות, שאסור לאחסן בבקרת המקור מכיוון שהן נוצרות מהמקור שהוא הקובץ הסכימטי.

מבנה הפרויקט הזה הוא רק נקודת מוצא. עליך להתאים אותו לצרכיך ולהוסיף חלקים לפי הצורך. בפרויקטים מסוימים כללנו תיקיית תוכנה או תיקיית מארז, שבה אחסנו מודלים למארזי הדפסה תלת מימדית לפרויקט.

שלב 7: שימוש ב- Git לפרויקטים של KiCad

סוף סוף אנו מוכנים לראות כיצד להשתמש ב- Git למעקב אחר הפרויקטים שלך. הוראה זו אינה מיועדת ללמד אותך כיצד להשתמש ב- KiCad (אם כי אני יכול לעשות זאת בעתיד אם יהיה ביקוש לכך), לכן נסקור מספר דוגמאות טריוויאליות להראות לך כיצד זרימת העבודה פועלת. צריך להיות קל להבין כיצד להתאים את הרעיונות הללו לפרויקט אמיתי.

פתח את ספריית kicad-starter ולאחר מכן הפעל את 'git log' כדי להציג את היסטוריית ה- commit. צריכה להיות כאן התחייבות אחת, אתחול הריפו על ידי בריינבו. הפעלת 'git status' תגיד לך את מצב הקבצים במאגר שלך (לא עוקבים, משתנים, נמחקים, מבוימים).

כרגע, לא אמורות להיות לך שינויים במאגר. בואו נעשה שינוי. פתח את פרויקט KiCad והוסף נגד לסכימה ולאחר מכן שמור. כעת הפעלת 'סטטוס git' אמורה להראות ששינית את הקובץ הסכימטי, אך עדיין לא ביצעת את השינויים האלה עבור התחייבות. אם אתה סקרן לדעת מה בדיוק עשה KiCad כשהוספת את הנגד, תוכל להריץ את הפקודה diff בקובץ שהשתנה 'git diff Circuit/Circuit.sch'. פעולה זו תדגיש את השינויים בין הגרסה הנוכחית של הקובץ בספריית העבודה לבין מצב הקובץ בהתחייבות האחרונה.

כעת, לאחר שעשינו שינוי, בואו ננסה לבצע את השינוי בהיסטוריית הפרויקטים שלנו. עלינו להעביר את השינויים מספריית העבודה שלנו לאזור הבימה. זה לא ממש מעביר את הקבצים במערכת הקבצים, אך מהווה דרך רעיונית ליידע את Git שביצעת את כל השינויים המתוכננים שלך עבור קובץ מסוים ומוכנים לבצע את השינויים האלה. מועיל, Git מספק כמה רמזים בעת הפעלת 'סטטוס git' לפעולה הבאה. שים לב להודעה `(השתמש ב" git add … "כדי לעדכן את מה שיתחייב)` תחת `שינויים שלא בוצעו לביצוע:`. גיט מספרת לך כיצד להעביר את השינויים לאזור הבמה. הפעל את 'git add Circuit/Circuit.sch' כדי לבצע את השינויים ולאחר מכן 'סטטוס git' כדי לראות מה קרה. כעת אנו רואים את הקובץ הסכימטי תחת שינויים שיש לבצע. אם אינך מעוניין לבצע שינויים אלה עדיין, Git מציע מועיל טיפ נוסף: '(השתמש ב- "git reset HEAD …" כדי לבטל את הבמה) `. אנו כן רוצים לבצע שינויים אלה, ולכן אנו מפעילים את 'git commit -m "הוסיף הנגד לסכימטי" ". זה מבצע את השינויים עם ההודעה שסופקה. הפעלת יומן git תציג התחייבות זו בהיסטוריית התחייבות הפרויקט.

עוד כמה טיפים על התחייבות.

1. אל תתחייב בכל שמירה. התחייב כאשר אתה מרגיש שהגעת לנקודה שבה השינויים שלך קצת התמצקו. אני מתחייב אחרי שאני מסיים סכמטי, לא אחרי כל הוספת רכיב. אתה גם לא רוצה להתחייב לעיתים רחוקות מדי, כי לזכור את ההקשר מדוע ביצעת את השינויים שביצעת 3 שבועות לאחר מכן יכול להיות קשה. להבין מתי להתחייב זו קצת אומנות, אבל אתה תרגיש יותר בנוח ככל שתשתמש ב- Git יותר.
2. מקור החנות בלבד (בעיקר). זה כולל את קובצי הפרויקט, הסכימות והפריסה, כמו גם ספריות ספציפיות לפרויקטים. זה יכול לכלול גם קבצי תיעוד. היזהר בעת אחסון אובייקטים נגזרים מכיוון שהם יכולים לצאת מסונכרן עם המקור המקורי בקלות, וזה גורם לכאבי ראש בהמשך. קובצי BOM ו- gerber מסונכרנים בקלות במיוחד, ולכן עדיף להימנע מהם (למרות שמדובר בהנחיות מפורטות יותר בשלב 9).
3. הודעות Commit הן שימושיות מאוד, אך הודעות התחייבות מובנות היטב הן בעלות ערך רב. מאמר מצוין זה מספק כמה קווים מנחים לכתיבת הודעות התחייבות ברורות, תמציתיות ושימושיות. פעולה זו עשויה לדרוש שימוש בעורך טקסט בשורת הפקודה, דבר שיכול לסבך אותי למתחילים ('git commit' ללא אפשרות ההודעה -m יפתח עורך טקסט). עבור רוב האנשים, אני ממליץ על עורך ננו. ל- StackOverflow יש הסבר טוב לשינוי העורך שלך

שלב 8: מתקדם: גרסאות סמנטיות לאלקטרוניקה

עבור הנשמות ההרפתקניות, הטיפים הבאים הם רעיונות מתקדמים, שנלקחו משעות רבות של פיתוח KiCad. הם אינם שימושיים במיוחד בפרויקטים קטנים יותר, אך הם יכולים באמת לחסוך לך עוגמת נפש כאשר הפרויקטים שלך גדלים במורכבותם.

בתוכנה יש מושג של גרסאות גרסאות סמנטיות (semver). סמבר מגדיר מתודולוגיית שמות נפוצה לזיהוי גרסאות תוכנה לפי "מספר גרסה", בהתאם לדפוס של "Major. Minor. Patch". כדי לצטט את המפרט של semver, אתה מקדם את מספר הגרסה בהתאם לקטגוריות השינוי הבאות.

1. גרסה גדולה כאשר אתה מבצע שינויי API לא תואמים,
2. גרסת MINOR כאשר אתה מוסיף פונקציונליות באופן תואם לאחור,
3. גירסת PATCH בעת ביצוע תיקוני באגים תואמים לאחור.

אנו ב- Brainbow משתמשים בגרסה משלנו למחצה המותאמת לצרכי פרויקטים של חומרה. המפרט שלנו עוקב אחר אותו דפוס "Major. Minor. Patch", למרות שההגדרות שלנו לגבי אילו שינויים נופלים תחת איזו קטגוריה כמובן שונות.

1. גרסה MAJOR: משמשת לשינויים משמעותיים בפונקציונליות הליבה של המעגל (למשל: מעבר מעבד מ- ATmegaa ל- ESP8266).
2. גרסה מינורית: משמשת להחלפות רכיבים שעלולות להשפיע על פעולת המעגל (למשל: החלפת פלאש SPI עם חלק תואם סיכה שעשויה להיות עם ערכת פקודות אחרת) או תוספת של תכונה נוספת מינורית (למשל: הוספת חיישן טמפרטורה נוסף).
3. גרסת PATCH: משמשת לתיקוני באגים קלים שלא ישנו את פעולת המעגל (למשל: התאמת מסך משי, התאמת פריסת קורט קלה, החלפות רכיבים פשוטות כמו 0603 קבלים ל 0805).

בחומרה חומרה, מספר הגירסה מתעדכן רק בייצור (בדיוק כמו בתוכנה, מספרי הגרסאות משתנים רק עם מהדורות, לא כל אדם מתחייב לפרויקט). כתוצאה מכך, לפרויקטים רבים יש מספרי גרסאות נמוכים. עדיין אין לנו פרוייקט להשתמש ביותר מ -4 גרסאות עיקריות.

מלבד היתרונות בעקביות ובהבנות שאתה מקבל ממעבר למערכת שמות מוגדרת היטב, אתה מרוויח גם יתרונות בתאימות קושחה ושביעות רצון לקוחות. ניתן לכתוב קושחה תוך התחשבות בגרסת הלוח שאליה היא מכוונת, ויהיה קל יותר לאתר באגים מדוע תוכנית מסוימת אינה פועלת על לוח מסוים ("נכון, הקושחה 2.4.1 אינה פועלת ב- 1.2 לוחות כי אין לנו… "). לקוחות נהנו גם מחומרת החומרה שלנו מכיוון ששירות לקוחות ופתרון בעיות קלים בהרבה עם תקן מוגדר.

שלב 9: מתקדם: שימוש בגרסת חומרה סמנטית

כדי להשתמש בחומרה בחומרה בפרויקטים שלך, אנו משתמשים בתכונת Git הנקראת תיוג. כאשר אתה מייצר לראשונה לוח, זוהי גירסת 1.0.0 של הלוח. ודא שביצעת את כל השינויים בפרויקט שלך ולאחר מכן הפעל את 'git tag -a v1.0.0'. פעולה זו תפתח עורך כך שתוכל לכתוב הודעת ביאור לתג זה (דומה מאוד להודעת התחייבות). אני כולל פרטים על הייצור (מי ייצר את הלוח המודפס, שהרכיב את הלוח), שיכול להיות מידע שימושי מאוחר יותר.

תג השחרור מתווסף להיסטוריית ה- commit ומציין את מצב הקבצים בייצור 1.0.0. זה יכול להיות שימושי במיוחד מספר תיקונים מאוחר יותר כאשר עליך לחזור לנקודה זו לפתרון בעיות. ללא תג שחרור מוגדר, יתכן שיהיה קשה להבין איזו התחייבות הייתה האחרונה בזמן הייצור. תג 1.0.0 (ו- 1.1, 1.1.1 וכו ') מאפשר לך לציין שקבצי המקור הספציפיים האלה היו אלה ששימשו בריצת ייצור מסוימת.

הערה על גרברס. כמה בתי פאב דורשים קבצי גרבר כדי להפוך את הלוח שלך, ותוכל ליצור אותם עם KiCad. אלה אובייקטים נגזרים, הנוצרים מהקובץ.kicad_pcb המקורי, ובדרך כלל איננו שולטים בקבצי גרסאות הנגזרים. אנו ב- Brainbow לא שומרים גרברים בבקרת גרסאות למעט כאשר אנו מתייגים מהדורה. כאשר אנו מוכנים לבנות, אנו יוצרים את קבצי הגרבר, מאחסנים אותם בתיקיית Fabrication ומתחייבים ומתייגים. לאחר מכן אנו מסירים את הגרברים ומחייבים את המחיקה. זה אולי נראה קצת מבלבל בהתחלה, אך הוא מבטיח שרגיל מבצע רק קבצי מקור לאחסן, והמהדורות המתויגות גם מאחסנות את הקבצים המדויקים המשמשים לייצור הלוחות. זה הוכח כשימושי להפליא במעקב אחר טעויות ייצור שבועות לאחר מכן.

שלב 10: השלבים הבאים

אני מקווה שהקדמה זו לימדה אותך מספיק כדי להתחיל להשתמש בבקרת גרסאות בפרויקטים אלקטרוניים משלך. לא הגענו לחלק מהנושאים המתקדמים יותר, כמו בקרת גרסאות לספריות המשותפות בין פרויקטים או ענפי תכונה. ובכל זאת, שליטה בגרסאות היא כמו לאכול את הירקות שלך: יתכן שאתה לא מקבל את מה שאתה חושב שאתה צריך, אבל כל פרק שאתה מקבל מקבל ספירות.

Brainbow עובדת על מדריך מפורט יותר לחלק מהתכונות המתקדמות יותר של זרימת העבודה שלנו. אנו מקווים לפרסם אותו מתישהו בחודשים הקרובים. עקוב אחרינו כאן ב- Instructables, ואנו נדאג ליידע אותך כאשר תוכל לקרוא אותו.

תודה שקראתם, ואנחנו כבר לא יכולים לחכות לראות מה אתם מכינים!