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

רקע ורעיונות קודמים

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

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

הכיוון הבא היה לשחזר את ההצלחה של המתאם הקודם שלי, רק בתכנון קומפקטי יותר. במקום לוח ארדואינו שלם, אפשר להרכיב על PCB קטן ג'וק CH340E (מ-USB ל-UART, כבר השתמשתי בו בעבר וראיתי שהוא בסדר), ג'וק מתאם מ-UART ל-RS485, ומיקרו-בקר כמו ATmega4809 שיתווך ביניהם, כי יש לו די והותר מודולי UART פנימיים. רגע, אם יש מתאם ל-UART ומתאם מ-UART, בשביל מה צריך תיווך ביניהם? ובכן, כשעובדים עם RS485 בשיטת Half duplex הנפוצה, קווי TX ו-RX של ה-UART לא מספיקים – צריך קו נוסף שיגיד לג'וק ה-RS485 מתי הוא משדר ומתי הוא קולט.

יש חיסרון גדול אחד לתכנון הזה: כדי שהוא יעבוד, המיקרו-בקר צריך לדעת מראש באיזה קצב שידור הוא אמור לעבוד. אין דרך להסיק את זה באופן ודאי ומיידי מהמידע שיוצא מה-CH340. המשתמש צריך להגדיר למתאם ידנית (באמצעות DIP Switch, ג'אמפרים, לחצנים או כל שיטה אחרת) את ה-baudrate הרלוונטי. לא הייתי מרוצה מזה, אבל לא ראיתי ברירה אחרת. פתחתי את KiCAD והתחלתי לתכנן את המעגל, כולל בונוסים קטנים כגון לדים לאינדיקציה של תקשורת פעילה.

שאלה של אינדיקציה מדויקת

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

את אופציית הלד אפשר לבטל אם קובעים שיפעל בלוגיקה הפוכה, למשל באמצעות טרנזיסטור PNP מתווך. במקום לציין Active, הלד יציין Idle – ואז אם לא אמורה להיות תקשורת (מצב קל לשחזור) והלד לא דולק, נדע שהוא הרכיב הבעייתי. את שתי האופציות האחרות נוכל לצמצם אם נגרום איכשהו לג'וק המתאם לשלוט בלד, במקום המיקרו-בקר. למעשה, במודולים הקנויים עם ה-CH340E כבר יש לד שמאיר כשיש תקשורת (מסומן כ-TXRX). איך זה נעשה שם?

בדקתי מודול כזה. הלד מחובר לפין שנקרא TNOW. נשמע הגיוני, Transmission Now או משהו כזה, לא? אבל חיפשתי עוד מידע ליתר ביטחון, ומצאתי אי-שם ברשת טענה שמדובר בפין אינדיקציה לשידור, מהסוג שצריך בשביל לתפעל ג'וק RS485 ולחסוך את התיווך של המיקרו-בקר! ה-Datasheet הוא בסינית, ובתרגום גוגל של הטקט שנראה רלוונטי קיבלתי את זה:

The TNOW pin indicates CH340 with a high level Data is being sent from the serial port, and it is low level after the sending is completed. In half-duplex serial port mode such as RS485, TNOW can be used to indicate the serial port.

מעולה… אבל אם כך, איך ייתכן שהלד על המודול נותן אינדיקציה גם ל-TX וגם ל-RX, כפי שכתוב לידו? העליתי ללוח ארדואינו קוד שמשדר משהו ב-Serial כל שנייה, וידאתי שהוא אכן משדר (באמצעות לד ונגד זמניים על קו TX שלו), ואז חיברתי אותו למודול. חושך מצרים. ה-Datasheet צודק, אפשר לראות רק שידור מהג'וק ולא אליו, והכיתוב TXRX סתם מטעה. קצת כמו הלד שמציין שהמודול מקבל חשמל, ושנקרא PHR במקום PWR…

השלמת התכנון החדש

השאלה שנותרה פתוחה, מבחינתי, היא האם (ועד כמה) האות שיוצא מפין TNOW המבטיח אכן מתאים לשידור RS485 Half duplex. כדי שזה יעבוד, הוא צריך להתחיל קצת לפני השידור בפועל ולהסתיים קצת אחריו, ומי מבטיח לנו שהג'וק הסיני אכן מוציא את הפלט הנכון? הלחמתי חוט דק לפין TNOW על המודול ובדקתי את הסיגנל שלו ושל TX באמצעות לוג'יק אנלייזר. הנה מה שקיבלתי בקצב שידור 115200 באוד:

המידע הקריטי בתמונה הוא פרקי הזמן מתחילת הסיגנל של TNOW (העליון) עד תחילת הסיגנל של TX, ומסיום TX עד סיום TNOW. שניהם נמדדו בתוכנה (סמנים אדומים וירוקים, שהנתונים מהם מופיעים מימין). 5 מיליוניות שנייה ו-11.5 מיליוניות שנייה, בהתאמה (לא לשכוח שיש Stop Bit אחרי הנתונים בשידור). "רוחב" של ביט יחיד הוא 8.68. מה לגבי קצבי שידור אחרים? ביצעתי מדידה דומה בקצב 9600 באוד:

כאן, הפרשי הזמנים הם 104.5 ו-107.8 מיליוניות השנייה, כאשר משך ביט רגיל הוא כ-104. מסקנות? ה-CH340E יודע מה קצב השידור מהמחשב, מתחיל את TNOW זמן של ביט אחד (פלוס מינוס) לפני השידור בפועל, ומפסיק אותו כ-3 מיליוניות שנייה אחרי סיום ה-Stop Bit. זה אמור להספיק לג'וק ה-RS485, ואם זה באמת יספיק, אוכל לוותר גם על המיקרו-בקר המתווך וגם על הקביעה הידנית של קצב השידור. הגיע הזמן להלחים אבטיפוס.

[כעבור זמן-מה…]

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

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