באיזה שפת תכנות משתמשים עבור תכנות של הלוח הזה?

[igendel]

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

לא האמנתי בחיים שאני אחזור לגעת ב-++C.

אומנם היא Object Oriented, לפחות זה,

אבל עדיין, שפה ישנה וגורמת לי ממש להרגשה של דחייה

אחרי שמשתמשים בשפות עם Frameworks, כמו Java ו-#C,

קשה מאד לחזור לזה.

כמו כן בשפות הנ"ל יש References, כך שאין צורך יותר בפוינטרים וכל הבלאגן..

המחירים כיום של מיקרו-בקרים הם זולים מאד - אפשר לקנות Arduino Pro Mini, עם ATMega328, במחיר של 4.5$.

המחיר בהחלט טוב,

אם רק היו משפרים את שפת הפיתוח - כלומר שיהיה אפשר לכתוב בשפה יותר חדשה(ועדיין במחיר זול עבור המיקרו-בקר), זה היה מושלם.

נקווה שזה יגיע.

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

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

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

[card]

כשאתה קונה לוח פיתוח עם מיקרו אתה עושה את בגלל שאתה רוצה להשתמש בפורטים השונים.

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

נכון.

או שאתה יכול עם Bluetooth..

לכל טלפון/טאבלט יש Bluetooth,

ואז אם אתה קונה מודול Bluetooth אתה יכול לקשר בינו לבין משהו אחר(Pro Mini), ואז לקבל GPIO..

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

עידו זו הקבלה לא נכונה..

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

המיקרו-בקר אמור לעזור לו להשיג את התוצאה כמה שיותר בקלות, ולא ההיפך.

המטרה היא שהבן אדם יוכל להתרכז במה שהוא רוצה להשיג.

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

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

המיקרו-בקרים יכולים היום להריץ יפה מאד .NET CF למשל.

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

השפות המודרניות שהזכרת לא בנויות לעולם המיקרו-בקרים

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

אבל בגירסאת מיקרו, הן בנויות יפה מאד.

דוגמא .NET Compact Framework

ועובד שיש כבר חברה שעושה את זה..

רק חבל שבגלל שהם היחידים, הם לוקחים מחירים מופקעים.

אגב אם karpatzio יכול לענות על זה:

אתה מודע לזה שיש references גם ב-C++

האם ה-References שאתה מדבר עליהם יעבדו גם על ה-++C של Arduino?

זה יהיה מאד שימושי אם כן

[karpatzio]

כן, אבל ישנם כמובן הבדלים. אני ישאיר לך לחפש אות בגוגל.

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

ו.... באמת? אתה מרגיש שיש לך עודף משאבים בארדוינו? כי אפילו בפרויקט הכי פשוט שאני עובד עכליו אני נזקק לבקרים משניים ורכיבי FPGA כדי להתגבר בדיוק על הבעייה ההפוכה. אם הייתי משתמש ברעה חולה כמו JAVA או C# למיקרו בקרים אני חושב שהייתי כבר מוותר מראש.

[igendel]

עידו זו הקבלה לא נכונה..

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

המיקרו-בקר אמור לעזור לו להשיג את התוצאה כמה שיותר בקלות, ולא ההיפך.

המטרה היא שהבן אדם יוכל להתרכז במה שהוא רוצה להשיג.

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

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

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

יש חברות שמנצלות את הנאיביות הזו של החובבים, זה נכון אבל האם זה נכון להשקיע את 90 האחוזים הנותרים של כוח העיבוד ב-Framework?

[card]

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

אבל האם זה נכון להשקיע את 90 האחוזים הנותרים של כוח העיבוד ב-Framework?

עידו ו-karpatzio,

יכול להיות שזה משתנה מאדם לאדם,

אבל ממה שאני רואה, גם אצלי וגם אצל חברים,

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

אלא יותר דברים אפליקטיביים כאלה.

דברים שהעיבוד בהם הוא מועט מאד..

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

לחיצה על מתג,

הפעלת ממסר,

קבלת אות IR או RF,

קבלת פקודות מהמחשב ב-Serial,

שליחת תוצאות למחשב דרך ה-Serial, או דרך ה-Bluetooth - שגם הוא Serial.

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

האם במקרה כזה, לא שווה שה"מוח" הזה יקריב קצת יותר תאים שלו, למען כתיבה נוחה יותר?

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

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

אתם מתקמצנים על ה-Framework?

בסדר.. אז בלי Micro Framework כלשהו.

אבל לפחות שזה לא יהיה עם פוינטרים

אפילו בפרויקט הכי פשוט שאני עובד עכליו אני נזקק לבקרים משניים ורכיבי FPGA כדי להתגבר בדיוק על הבעייה ההפוכה.

יכול להיות שהפרויקטים ש-karpatzio עובד עליהם, הם פרויקטים של עבודה ודברים כאלה,

לכן הוא מרגיש דווקא חוסר, ולא עודף.

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

לנו כמות המשאבים במיקרו-בקר היא עודפת,

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

[karpatzio]

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

עריכה:

אולי אני יחדד קצת את הכוונה שלי.

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

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

[igendel]

לחיצה על מתג,

הפעלת ממסר,

קבלת אות IR או RF,

קבלת פקודות מהמחשב ב-Serial,

שליחת תוצאות למחשב דרך ה-Serial, או דרך ה-Bluetooth - שגם הוא Serial.

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

[card]

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

ופה לא עובד

נניח והגדרתם כמה const-ים,

לדוגמא:

const unsigned long Btn_Play =0x843502FD;

const unsigned long Btn_Stop =0x843503FC;

const unsigned long Btn_Pause =0x843501FE;

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

class IR_Remote__Creative

{

public:

static const unsigned long Btn_Play =0x843502FD;

static const unsigned long Btn_Stop =0x843503FC;

static const unsigned long Btn_Pause =0x843501FE;

};

עד כאן הכל עובד.

אבל עכשיו, בתוכנית שלכם,

אם תכתבו switch(),

ואז תשימו בו:

case IR_Remote__Creative.Btn_Play:

Serial.println("Play");

break;

case IR_Remote__Creative.Btn_Stop:

Serial.println("Stop");

break;

הקומפיילר נותן שגיאה:

IRrecvDemo.ino: In function 'void loop()':

IRrecvDemo:73: error: expected primary-expression before '.' token

IRrecvDemo:73: error: `.' cannot appear in a constant-expression

עריכה:

החלפתי את ה-'.' ב-'::',

ועכשיו זה התקמפל סוףסוף.

אבל למה אני לא יכול עם נקודה?

יש איזה משהו שאני יכול לשנות בהגדרת הקלאס,

כדי שפנייה לקבועים בתוכו תיעשה בעזרת נקודה?

[Mike-]

בצורת C לבקרים הייתי מגדיר את הקבועים האלה בתור #Define, אולי בתוך קובץ Header חדש של קבועים בשביל הסדר.

אני לא מבין בC++ אבל יכול להיות שהאופרטור . מבלבל אותו כי הקבוע אמור להמצא בזכרון התוכנית ?

[card]

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

כך שאוכל לעשות לה include כשצריך.

לגבי הסיבה לכתיב המסוים,

זה מסוג הדברים שבשפות חדשות יותר הם כבר polished,

ובשפות ישנות כמו ++C הם לא.

כמובן זה גם עניין של הרגל..

מי שעבד בשנים האחרונות עם ++C, זה טבעי לו.

מי שעבד עם שפות חדשות יותר, לכתוב פתאום ++C זה ממש סבל.

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

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

[karpatzio]

לא כמו שאתה רוצה.

אופרטור ה. מתייחס לשדות ומתודות ברמת האובייקטים (instances(.

אופרטור ה-:: מתייחס לשדות ומתודות ברמת המחלקה או יותר נכון, הnamespace.

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

[card]

אני מבין.

[igendel]

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

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

[card]

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

ב-OOP יש כמה רעיונות..

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

פה הקלאס הוא לא ממש פעולתי.. אין בו מכניזם,

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

יש קלאס כזה לכל סוג של שלט IR שיש לי.

[karpatzio]

האמת שלצורך הזה הייתי כותב משהו כמו:

namespace RCCodes
{
blah code 1 = 423423423
blah code 2 = 4523543534
}

וניגש כמו שאתה עשית.