שְׁאֵלָה:
באילו דפוסי עיצוב אוכל להשתמש בכדי לטפל בקלט המשתמשים ובעדכון התצוגה?
Cybergibbons
2014-03-01 15:46:44 UTC
view on stackexchange narkive permalink

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

באילו דפוסי עיצוב ניתן להשתמש בכדי להתמודד עם קלט המשתמש (מכפתורים ) ועדכון תצוגות מבלי לגרום לבעיות אלה?

כרגע אני משתמש בסוג הבא של דפוס (זה פשוט עד למינימום):

  #include <Bounce.h> #define GREEN_LED 6 // Pin for LED green # define BUTTON_PIN 15 // Pin for button - משתמש חיצוני למשוך כלפי מטה כל כך פעיל גבוה # להגדיר DISPLAY_REFRESH_INT 100 // כמה MS בין עדכוני תצוגה Bounce button = Bounce (BUTTON_PIN, 5); // כדי לאותת בין כפתור הקריאה לתצוגה updatebool ledState = false; // משמש כדי לעקוב אחר התצוגה האחרונה displayatelonglangupdate = 0; התקנת החלל () {pinMode (GREEN_LED, OUTPUT); pinMode (BUTTON_PIN, INPUT);} loop loop () {// קרא את מצב הלחצן if (button.update ()) {if (button.risingEdge ()) {ledState =! ledState; }} // עדכן את התצוגה מעת לעת אם (millis () - displayUpdate > DISPLAY_REFRESH_INT) {displayUpdate = millis (); digitalWrite (GREEN_LED, ledState); }}  

אילו אפשרויות אחרות יש? האם כדאי להשתמש בהפסקות החלפת סיכה לקריאת כפתורים (אם איננו שוקלים חיי סוללה!).

ארבע תשובות:
Peter Bloomfield
2014-03-01 17:50:10 UTC
view on stackexchange narkive permalink

התשובה תלויה בדיוק באיזה אופן נועדה התגובה להגיב לאינטראקציה של המשתמש.

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

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

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

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

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

  unsigned int g_section = 0; setup void () {} void pollButton () {//...}oid runSection0 () {//...}void runSection1 () {//...}void runSection2 () {//...}oid loop () {// סקר את הכפתור בכל מעבר: pollButton (); // בצע את החלק הבא של הקוד הראשי: switch (g_section) {case 0: runSection0 (); לשבור; מקרה 1: runSection1 (); לשבור; מקרה 2: runSection2 (); לשבור; } // באיטרציה הבאה, הפעל את החלק הבא: אם (++ g_section > 2) g_section = 0;}  

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

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

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

זו אגב תשובה נהדרת. בדיוק סוג התשובה שהאתר זקוק לה.
Chris K
2014-03-06 07:17:51 UTC
view on stackexchange narkive permalink

לבקרת התוכנה, הכנתי משהו ממסגרת הטיפול בתפריט עבור אחד הפרויקטים שלי ו שיתפתי את המקור ב- Github. שים לב שזה מיועד ל- chipKIT אך קוד הטיפול בתפריט הוא כללי. לאחר שבניתי את מבנה ה- if-else-if והמתג הענק שלי השלישי או הרביעי, החלטתי שחייבת להיות דרך טובה יותר. קרדיט למקור מבני התפריטים הסטטיים.

אני פשוט משתמש בלולאה הראשית כדי לבדוק את הכפתור.

I אני רוצה לומר שהצעד הראשון הוא להשיג TFT. אם תנסה את זה, לעולם לא תחזור ... אני אוהב במיוחד את ה- TFT Adafruit 1.8 "עם ג'ויסטיק. Arduinos הם איטיים מספיק כדי שלא אוכל לזכור שדאגתי להפחית את קלט המשתמשים.

אני אוהב את הדרך שעשית את זה - זה מובן, נקי וגודל קטן מאוד. בחנתי שימוש בספרייה (MenuBackend) אך קשה להבין עבור מתכנתים חדשים (המשתמשים בשיחות חוזרות) ואינני יכול לשבת ב- PROGMEM.
אני חושב שלעתים קרובות אין צורך בהנחיות, אך נראה כי מתגים מסוימים רועשים בהרבה מאחרים. מתגי המישוש ה- PCB הזקופים, המותקנים בקצה, נראים הכי גרועים, אולי מכיוון שבמקום ללחוץ, משתמשים לעיתים קרובות ממריצים אותם קדימה. ההפקרות הן כל כך קלות שאני כמעט תמיד עושה את זה עכשיו.
סליחה על כל השאלות - למה TFT? כרגע אני עובד עם LCD בגודל 128x64 שיש לו הרבה יתרונות (בעיקר להיות גדול פיזית). גם זול.
@Cybergibbons אה, לא ראה שום אזכור לתצוגה. זה שאני אוהב הוא מגן מוכן, זול מספיק, ואתה יכול לעשות דברים עם צבעים. הנה דוח בנייה של הפרויקט האחרון שלי: http://forums.adafruit.com/viewtopic.php?f=22&t=44710&p=223543#p223543
JRobert
2014-03-03 05:19:02 UTC
view on stackexchange narkive permalink

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

אך לשאלה העיקרית, אוסף של מכונות מדינה יכול להיות מאוד שימושי, לפחות עבור ממשק המשתמש, ותן לך את מרבית היתרונות של ריבוי משימות ללא צורך בגרעין am / t. למרבה הצער יכולה להיות במכשירים מוגבלים בזיכרון RAM מכיוון ש

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

neu-rah
2017-03-04 01:56:11 UTC
view on stackexchange narkive permalink

ככריס K יישמתי גם ספריית תפריטים סטטית עם מגוון רחב של אפשרויות פלט כמו Serial, LCD, TFT וכו '. התחלתי אותה כדי לעזור בפרויקט חברים ואני גם משתף אותו קוד פתוח לאנשים עם בעיות דומות, מקווים שתוכלו למצוא את זה שימושי.

https://github.com/neu-rah/ArduinoMenu



שאלה ותשובה זו תורגמה אוטומטית מהשפה האנגלית.התוכן המקורי זמין ב- stackexchange, ואנו מודים לו על רישיון cc by-sa 3.0 עליו הוא מופץ.
Loading...