שְׁאֵלָה:
האם ה- C ++ STL נתמך באופן מלא בארדואינו?
NonCreature0714
2016-06-01 22:27:09 UTC
view on stackexchange narkive permalink

אני עדיין לא מחזיק בלוח ארדואינו להפעלת קוד, וכמו שהכותרת אומרת, אני סקרן אם ה C ++ STL נתמך באופן מלא בארדואינו וכבר חלק מ ארדואינו IDE. ה- STL הוא כנראה היעיל ביותר, הנבדק במלואו והמינימלי ביותר למשאבים (שהוא ביטוי מיותר מעט, כפי שכבר הזכרתי יעילות), קוד C ++ זמין לציבור שם, ויהפוך את החיים לקלים הרבה יותר לקידוד עבור Arduino.

אם ה- STL אינו חלק מ- Arduino IDE, אז כיצד לכלול ספריות ספציפיות כגון <algorithm> ו- <utility> ? (אני מתפתה מאוד לשאול "מדוע זה לא נכלל?" אבל זה נראה רחב מדי.)

הבעיה ב"יעילה "היא שהיא לא מציינת רק * כמה * יעילה; האם הוא יפעל טוב במכשיר 16 מגה-הרץ עם זיכרון RAM של 2 קילו-בייט בלבד?
`וכבר חלק מה- IDE של ארדואינו` - בפעם האחרונה הסתכלתי שזה לא היה. באופן אישי אני אוהב את ה- STL וחושב שצריך לכלול אותו. האם אתה יכול לסבול את התקורה או לא זו בהחלט החלטה עבור משתמש הקצה? התקנתי את ספריית Maniacbug די לאחרונה, ונראה שהיא עובדת בסדר.
ארבע תשובות:
Malachi
2016-06-01 22:39:10 UTC
view on stackexchange narkive permalink

ה- STL אינו חלק מארדואינו IDE.

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

https://github.com/maniacbug/StandardCplusplus

בדקו את המזלגות, הם נראה מעודכן יותר

אני נגד הקונצנזוס הזה: p אז זה כבר לא ממש קונצנזוס? ; p יש להשתמש בו בחוכמה, אך יכול להיות חזק / שימושי מאוד. לא כל זה עשוי לעבוד גם כן. אבל השתמשנו ב- std :: תור ליצירת תור הודעות שהארדואינו יסיר. בתיאוריה זה יכול להיות מוגזם, אך בדרך כלל הוא יעיל יותר במקום כקביעת מאגר קבוע. מכיוון שצריך להגדיר את המאגר מספיק גדול, אבל בסופו של דבר תמיד "ישתמש" בזיכרון המלא של המאגר.
@Paul האם תוכל בבקשה להסביר מדוע יש לך נקודת מבט אחרת? אני בטוח שזה מעניין / חינוכי.
@Paul האם אתה משתמש בגרסת maniacbug או בטעם אחר? בבקשה שתף. STL נראית לי מעניינת, אך היא נוטה מעט להקצאה דינמית וה- rtti הצחיק רבים (כולל עצמי) להשתמש בה לתרחישים של AVR
ערכתי את תשובתי, בעצם הפיכת מאגר קבוע לאחסון שלך היא פחות יעילה במקום בשימוש באחסון דינמי. אתה תסתבך רק כשנגמר לך הזיכרון, ומכיוון שקשה לחזות את זה מכיוון שדינמי. אבל באופן כללי צריך להיכשל מאוחר יותר.
זה היה למעשה בשנה השנייה שלי, השתמשנו בשרשרת הכלים GNU-GCC עם, אני מאמין AVR-GCC, avrdude ו ליקוי חמה. אבל אני לא יודע איך הגענו לרמה, זה נראה קל באותה תקופה
שרשור עם כמה אפשרויות ומחשבות STL אחרות: https://forum.arduino.cc/index.php?topic=360116.0
איבדתי את שרשרת הכלים מאז שקיבלתי מחשב נייד חדש. שאני מרחם עליו מאוד, אבל יש לי את הקוד מהפרויקט ההוא. אני אבדוק עם כמה חברים לכיתה אם הם מצליחים למצוא את המסמך להגדרת GCC עבור AVR עם STL
אבל אני חושב שכדאי לנסות, במיוחד עם המיקרו-בקרים החדשים יותר, עם יותר זיכרון RAM. אם תנסה את זה, זה באמת יכול לעבוד טוב מאוד.
אפילו עם זיכרון RAM מוגבל, אם תנסה לכתוב רשימה מקושרת משלך, ייתכן שתגלה שאתה לא עושה עבודה טובה יותר מ- STL.
שנים אחר כך, אך ברצוני לציין חלופות משכנעות: `etl` (https://github.com/ETLCPP/etl) ו-` estdlib 'שלי (https://github.com/malachi-iot/estdlib )
Dmitry Grigoryev
2016-06-02 19:54:30 UTC
view on stackexchange narkive permalink

STL יעילה בפלטפורמה שהיא תוכננה לה, שהיא מחשבים אישיים ומכשירים בקנה מידה דומה, כאשר הקצאת בתים בודדים בערימה צורכת עמוד זיכרון של 4k (זה פי כמה מ- RAM של כל Arduino), כאשר אינדקסים של מערכים יכולים להיות מוחלפים ביעילות באמצעות מצביעים (מיקרו-בקרים של 8 סיביות זקוקים לפחות לשתי פקודות כדי להתמודד עם מצביע). אז לא, זה לא יעיל עם Arduino.

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

אלא אם כן הספריה נכתבת מחדש עבור AVR. בתיאוריה זה יהיה טוב / יעיל יותר כשאני מנסה לתכנת תור או תור עדיפות ב- C. אם אתה באמת זקוק להתנהגות, אתה צריך לשקול לפחות או לנסות את זה.
באופן אישי הייתי משתמש ביציאת AVR של C ++ STL שנמצאת ב- GitHub, ומפריע לאנשים ב- GitHub אם יש לך יישום טוב יותר, בדרך זו נוכל לגרום לזה לעבוד, במקום שכל אחד יבחר ליצור את היישום שלו;) מכיוון שהוא נמצא ב- GitHub (ואולי אפילו יש לו מספר תורמים) והוא מכוון ל- AVR. זה אמור לבצע ביצועים סבירים ולהיבדק על ידי מספר רב. שזה כנראה טוב / מהיר יותר כקוד כלשהו בכתב עצמי. אבל אני מסכים מצד: "השתמש בזהירות". אבל לא "אל תשתמש כי גרסת המחשב האישי לא תהיה טובה.".
@Paul אם STL היה כתוב מחדש עבור AVR, הוא יאבד אוטומטית את המצב "נבדק / בוגר לחלוטין", לא?
ובכן, אם הייתם מיישמים את זה בעצמכם, הוא יאבד אוטומטית גם את המצב שנבדק במלואו: p ואם אתה משתף פעולה ב- github, זה נבדק באופן מלא יותר כמו כשאתה עושה את זה לבד? (:
בנוסף, ב- STL נבדק באופן מלא; כן זה, למחשב. (:
Paul
2016-06-02 19:00:46 UTC
view on stackexchange narkive permalink

ה- STL אינו חלק מארדואינו ואין תמיכה ב- libstc ++ מ- AVR.

ההבדלים בין "התשובה" שלי ממלאכי בשלב מסוים, כפי שמוסבר בתגובות.

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


מדוע להשתמש ב- libstdc ++?

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

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

אז ב- C, תשתמשו ב -250 בתים של זיכרון בכדי לשמור את ההודעות שלכם. כל הודעה ארוכה יותר לא תתאים.

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

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

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

כמו כן, יצירת אחסון דינמי משלך ב- C עלולה לגרום לבעיות רבות יותר מ- C ++ stl;). וזה לא כאילו אתה צריך להשתמש באחסון דינמי לכל דבר, פשוט היכולת לעשות זאת זה נחמד.


בקרי המיקרו הנוכחיים גם הם הופכים להיות הרבה יותר רציניים כמו Arduino של 8 סיביות (328P). 20 $ יכול להשיג לך Teensy 3.2 שיש לו 256K Flash Flash, 64K RAM כך שבמקרה זה זיכרון דינמי יכול להיות שימושי מאוד (אם אתה בטוח שנשאר לך מספיק זיכרון). כמו כן: כל מוצרי STM32F41xxx מוטבעים: עד 192 קילו-בייט של מערכת SRAM כולל 64 קילו-בתים של זיכרון נתונים של CCM (זיכרון ליבה)

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


כיצד להשתמש בספריית התבניות הרגילה C ++ עבור AVR?

עקבתי אחר הבלוג מ- אנדי בראון וכעת פועלים איטרטורים / מחרוזת / ווקטורים ב AtmelStudio.

למרות שקיבלתי כמה שגיאות, קבוצת השגיאות הראשונה כללה:

  שגיאה '_M_deallocate' לא הוכרזה בהיקף זה, ולא נמצאו הצהרות על ידי תלוי ארגומנט בדיקת נקודת ההתיישרות [-מתיר] D: \ avr-stl \ include \ string 173 הצהרות הודעות בבסיס תלוי 'std :: _ String_alloc_base<char, std :: allocator<char>, true>al' לא נמצאות על ידי unifi ed lookup D: \ avr-stl \ include \ string 173 הודעה השתמש ב- 'this->_M_deallocate' במקום D: \ avr-stl \ include \ string 173  

שגיאה זו למעשה מסבירה את עצמה; עליך להשתמש ב this->_M_deallocate .

לאחר מכן קיבלתי התייחסות לא מוגדרת ל"מפעיל חדש (int חתום, בטל *) . אבל תיקנתי אותו על ידי הכללת "pnew.cpp" ממש מתחת ל #include <new> ב stl_construct.h שזה מוזר, אבל זה עובד.

(חתיכת stl_construct.h)

  #ifndef __SGI_STL_INTERNAL_CONSTRUCT_H # הגדר __SGI_STL_INTERNAL_CONSTRUCT_ #include <new> # include <pnew.cpp>__STL_BEGIN_NAMESPACE  
לאחר בדיקת כמה דברים באינטרנט, אכן נראה כי הקצאה סטטית לרוב טובה יותר מהקצאה דינמית. מכיוון שהבעיות (הצפות אפשריות, פחות שליטה ופיצול ערימה) אינן צפויות להכביד על היתרונות. אבל, זה לא אומר שכולם צריכים להפסיק להתנסות בזה;) וגם שזה לא יכול להיות שימושי בכמה יישומי נישה (לכן זה לא דבר רע "להתקין" אותו).
קהל קשוח, אני לא חושב שמגיע לך שלילי על תשובתך! פיצול ערימה הוא אחד הדברים העיקריים שמרחיקים אותי מהזיכרון הדינמי ב- AVR. עם זאת, בשבבים גדולים יותר אני אוהד - כאשר משתמשים בזהירות.
scls
2018-05-04 01:18:18 UTC
view on stackexchange narkive permalink

ה- STL אינו חלק מ- Arduino IDE.

תשובה אחרת היא אזכור של https://github.com/maniacbug/StandardCplusplus למרות שספריה זו לא נראית נשמר עוד.

אולי רעיון טוב יותר יכול להיות לנסות https://github.com/mike-matera/ArduinoSTL

זה נמל של uClibc ++ ארוז כספריית Arduino.



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