გამარჯობა, ჰაბრ!
დღეს მე გეტყვით ისეთ საინტერესო საკითხზე, როგორიცაა ოპერაციული სისტემარეალურ დროში (RTOS). დარწმუნებული არ ვარ, ეს საინტერესო იქნება გამოცდილი პროგრამისტებისთვის, მაგრამ ვფიქრობ, დამწყებთათვის მოეწონება.

რა არის RTOS?

თუ ვიკიპედიას გადავხედავთ, ვნახავთ 4 განმარტებას.
მოკლედ რომ ვთქვათ, RTOS არის ოპერაციული სისტემა, რომელიც რეაგირებს გარე მოვლენებზე გარკვეული დროის განმავლობაში. აქედან გამომდინარე, ჩვენ შეგვიძლია გავიგოთ RTOS– ის მთავარი მიზანი - მოწყობილობები, რომლებშიც საჭიროა მოვლენებზე სწრაფი რეაგირება (თუმცა, არავითარ შემთხვევაში არ აურიოთ RTOS ოპერაცია შეფერხებებთან).

რატომ გვჭირდება ის?

ამის საკმაოდ ბევრი მიზეზი არსებობს.
პირველი, RTOS მხარს უჭერს მრავალ ამოცანას, პროცესის პრიორიტეტებს, სემფორებს და სხვა.
მეორეც, ის ძალიან მსუბუქია და თითქმის არ საჭიროებს რესურსებს.
მესამე, ჩვენ შეგვიძლია მივიღოთ ყოველივე ზემოთქმული თითქმის ნებისმიერ აპარატურაზე (მაგალითად, FreeRTOS მუშაობს თუნდაც 8 ბიტიან AtMega– ზე).
და მეოთხე: უბრალოდ ითამაშეთ და გაერთეთ.

3 ცნობილი RTOS მიმოხილვა.

ყურადღება: რაც ქვემოთ მოყვება არის ჩემი პირადი აზრი.

FreeRTOS

ერთ -ერთი ყველაზე პოპულარული RTOS დღეს. გადატანილია უზარმაზარი რაოდენობით რკინა. Ოფიციალური გვერდი.

დადებითი

1) უფასო
2) გადატანილია დიდი რიცხვიჯირკვალი
3) ძლიერი ფუნქციონირება
4) არსებობს სხვადასხვა ბიბლიოთეკა: გრაფიკა, ინტერნეტი და სხვა.
5) კარგი დოკუმენტაცია.

მინუსები

1) ახალ აპარატურაზე გადატანის საკმაოდ რთული პროცესი.

დასკვნა: ეს არის ნამდვილად პროფესიონალური RTOS კარგი დოკუმენტაციით. დამწყებთათვის კარგი იქნება, თუ მის აპარატურაზე უკვე არის პორტი.

KeilRTX

ბოლო დრომდე, ეს RTOS იყო კომერციული, მაგრამ ცოტა ხნის წინ გახდა ღია. მუშაობს მხოლოდ მკლავის არქიტექტურაზე. Ოფიციალური გვერდი.

დადებითი

1) უფასო
2) ადვილად პორტირებული ახალ ტექნიკაზე (მკლავის არქიტექტურაში).
3) არსებობს სხვადასხვა ბიბლიოთეკა: გრაფიკა, ინტერნეტი და სხვა.

მინუსები

1) მასთან კეილთან მუშაობა თითქმის შეუძლებელია
2) ოდნავ ჩამოშორებული ფუნქციონირება
3) მხოლოდ მკლავია მხარდაჭერილი.
4) (ჩართულია პირადი გამოცდილება) კარგავს ბევრ RTOS სიჩქარეს.
დასკვნა: იდეალურია დამწყებთათვის და მცირე პროექტებისთვის.

uc / os

ძლიერი კომერციული RTOS. ვებგვერდი.

დადებითი

1) უზარმაზარი რაოდენობის ფუნქციები და ბიბლიოთეკები.
2) მხარს უჭერს ბევრ რკინას

მინუსები

1) კომერციული.
2) გამოყენება რთულია.

დასკვნა: დამწყებთათვის მას ეძახიან RTOS.

სხვა საინტერესო RTOS

RTLinux RTOS, რომელიც დაფუძნებულია ჩვეულებრივ Linux- ზე.
QNX RTOS დაფუძნებულია უნიქსზე.

განვითარების მახასიათებლები RTOS– ის გამოყენებით

პირველ რიგში, თქვენ უნდა გესმოდეთ შემდეგი: RTOS არ არის Windows. მისი დაყენება შეუძლებელია. ეს სისტემა უბრალოდ შედგენილია თქვენი პროგრამით.
RTOS– ით პროგრამების წერისას, მათი ჩვეული მნიშვნელობით ფუნქციები არ გამოიყენება. ფუნქციების ნაცვლად გამოიყენება პროცესები (ან ამოცანები). განსხვავება ისაა, რომ პროცესები, ფუნქციებისგან განსხვავებით, უსასრულო მარყუჟებია და არასოდეს მთავრდება (თუ ვინმე ან ის თვითონ არ მოკლავს მას - ანუ გადმოტვირთავს მას მეხსიერებიდან).
თუ რამდენიმე პროცესი ჩართულია, RTOS ცვლის მათ, თავის მხრივ აჩვენებს მანქანის დროს და რესურსებს. სწორედ აქ ჩნდება პროცესის პრიორიტეტის კონცეფცია - თუ ორ პროცესს ერთდროულად სჭირდება მანქანების დრო, მაშინ RTOS მისცემს მას უმაღლესი პრიორიტეტით.
RTOS– ში არსებობს სპეციალური შეფერხების ფუნქციები - ისე, რომ დრო არ დაიკარგოს ერთი პროცესის შეფერხების დროს, მეორე შესრულდეს.
ახლა მოდით ვისაუბროთ ისეთ საკითხზე, როგორიცაა სემაფორი - ეს არის ის, რაც აკონტროლებს პროცესის წვდომას პროგრამის რესურსებზე. თითოეული რესურსისთვის არის მარკერი - როდესაც პროცესს სჭირდება რესურსი, ის იღებს მას და იყენებს ამ რესურსს. თუ არ არის მარკერი, მაშინ პროცესი უნდა დაელოდოს მის დაბრუნებას. მე მოვიყვან მაგალითს: სხვადასხვა პროცესი აგზავნის ინფორმაციას ერთ UART– ზე. რომ არ არსებობდეს სემაფორი, მაშინ ისინი რიგრიგობით აგზავნიდნენ ბაიტებს და ეს არეულობა იქნებოდა. ასე რომ, პირველმა პროცესმა აიღო მარკერი UART– ზე, გაგზავნა შეტყობინება და მისცა მეორეს (და ასე შემდეგ - ad infinitum).

დამატებითი RTOS ბიბლიოთეკები.

RTOS ხშირად გვთავაზობს სხვადასხვა ბიბლიოთეკას სამუშაოდ, მაგალითად, გრაფიკით, ინტერნეტით და ა. ისინი მართლაც კომფორტულია და არ უნდა მოგერიდოთ მათი გამოყენება. ამასთან, გახსოვდეთ, რომ RTOS– ის გარეშე, რისთვისაც ისინი დაწერილია, ისინი არ იმუშავებენ.
Აი ზოგიერთი მაგალითი:
RTX– ისთვის

რა მოდის გონებაში, როდესაც გესმით ოპერაციული სისტემა? რა თქმა უნდა, ხვრელები, Linux, Macos .. ან რამე მსგავსი. ეს ასეა და კითხვაზე, თუ რატომ არის საჭირო, ყველა დარწმუნებით უპასუხებს: მოუსმინეთ მუსიკას, ითამაშეთ თამაში (ინტერნეტში!), მეგობართან სკაიპში საუბრისას. ამავე დროს, იმაზე ფიქრი, როგორ ანათებს LED, რომელმაც მიიღო ბაიტი uart =).

და თუ უფრო ღრმად ჩახვალთ, მუსიკის მოსმენა, ინტერნეტით მონაცემების გაგზავნა არის ყველა ერთი პროცესი და რადგან ჩვენ გვაქვს ერთი პროცესორი, მას შეუძლია ერთდროულად მხოლოდ ერთი ამოცანის შესრულება. ამრიგად, ამოცანები სათითაოდ სრულდება მცირე "ნაწილებში", OS- ს არსი იმაში მდგომარეობს, რომ ის მომხმარებლისთვის შეუმჩნევლად გააკეთოს: ისე, რომ ხმა არ ისუნთქოს და ველოსიპედი გათიშოს და ყველაფერი ერთდროულად იმუშაოს. ამავდროულად, თუ რომელიმე ამოცანა "დაკიდება", მაშინ დანარჩენმა ყველაფერი განაგრძო მუშაობა.

თუ ჩვენ გადავაგდებთ ყველა დამატებით ფუნთუშას და დავტოვებთ შიშველ არსს, მაშინ უპირველეს ყოვლისა OS არის მხოლოდ ტაიმერი, რომელიც ითვლის დროის თანაბარ ინტერვალს და ასევე გადადის ამოცანებს შორის მომხმარებლის ჩარევის გარეშე, ასრულებს გარკვეულ ნაწილს და ისევ იცვლება. თქვენ ასევე უნდა გაითვალისწინოთ, რომ უმეტეს ამოცანებს შეიძლება არ ჰქონდეთ დრო ერთ ნაწილად დასრულებისთვის, ასე რომ თქვენ უნდა შეინახოთ ამოცანის მდგომარეობა მეორეზე გადასვლის დროს და შემდეგ ჯერზე მდგომარეობის აღდგენისთვის ცვლადები. ამ ყველაფერს მართავს ამოცანების შემდგენელი.

არსებობს ორი ძირითადი ტიპის ოპერაციული სისტემა: პრევენციული და კოოპერატიული. პირველ შემთხვევაში, ამოცანებს შორის გადართვა იქნება "რთული", ე.ი. თუ დროის მონაკვეთი არის 1 ms, მაშინ პირველი ამოცანა შესრულდება ზუსტად 1 ms, შემდეგ მეორე ზუსტად 1 ms და ა.შ. ასეთ ღერძებს ეწოდება რეალურ დროში (RTOS). კოოპერატივისთვის, ეს ცოტა უფრო მარტივია, თავად პროცესმა უნდა თქვას, რომ "მე შევასრულე", ამიტომ მათ არ შეიძლება მივაკუთვნოთ RTOS.

ის არ იმუშავებს რაიმე მიზეზის გამო მცირე AVR– ზე გადატანაზე მცირე რაოდენობაოპერატიული მეხსიერება. კოოპერატივების არსებული ვარიანტებიდან მომეწონა mRTOS, თქვენ შეგიძლიათ წაიკითხოთ ამ სისტემის დეტალები ავტორის ვებგვერდზე (ადვილად გუგლში). მთავარი მიზეზიმისი გამოყენება - სიმარტივე, CAVR– ის მზა ვერსიის ხელმისაწვდომობა, გასაგებად ზოგადი პრინციპებიძალიან რამ

ასე რომ, მთავარი კითხვები რჩება, რატომ და როდის გამოვიყენოთ ღერძი. თეორიულად, ყველაფერი იგივეა, რასაც თქვენ აკეთებთ ღერძთან, შეგიძლიათ ამის გარეშე, რადგან რესურსები იგივეა. იქიდან გამომდინარე, რომ თქვენ მას ადაპტირებთ პროექტზე, მეგაჰერცი არ გაფრინდება კოსმოსში, რკინა იგივე დარჩება, შესაბამისად რესურსები იგივეა.

აქედან გამომდინარე, ღირს დაუსვათ საკუთარ თავს რამდენიმე კითხვა:
1. შეგიძლიათ გონივრულად მართოთ თქვენი რესურსები?
2. განა firmware– ის წერის პროცესში არ იგულისხმება იგივე ველოსიპედის ხელახალი გამოგონება, გრაფიკის მსგავსი?
3. რამდენად იკითხება თქვენი კოდი? შეგიძლიათ გახსნათ ის ექვს თვეში ან წელიწადში და დაუყოვნებლივ გაარკვიოთ?
4. წერ მარტო თუ ჯგუფურად?

ძნელია უპასუხო პირველ კითხვას, რადგან ყველაფერი დამოკიდებულია დეველოპერის გამრუდებაზე. მეორესთან ერთად, ეს უფრო და უფრო ნათელია, თუ ბევრი დამოუკიდებელი ამოცანაა და დაგეგმილია მათი რეგულარული ინტერვალებით შესრულება, მაშინ უმჯობესია OS– სკენ იყუროთ. მესამესთან ერთად, ასევე ნათელია, რომ გაცილებით ადვილია ცალკე ამოცანის გაგება, ვიდრე დამოკიდებულების არჩევა მთავარ მარყუჟში. თუ მარტო არ წერთ, მაშინ აქაც არის უპირატესობები, რადგან ყველას შეუძლია დაწეროს საკუთარი პრობლემა ცალკე, დანარჩენში ჩარევის გარეშე.

ყოველივე ზემოაღნიშნულის შერწყმით, გამოყენების სფერო საკმაოდ სპეციფიკურია, გარკვეული ამოცანებისათვის. თქვენ არ უნდა ჩადოთ იგი ყველა პროექტში. რადიო სამოყვარულო ხელნაკეთობების უმეტესობისთვის, ღერძი ზედმეტია, მაგრამ ადრე წარმოდგენა რომ მქონდეს, ალბათ რამდენიმე პროექტში გადავიტანდი.

ახლა მოდით შევხედოთ hood ქვეშ. MRTOS- ის გასაშვებად, თქვენ უნდა დაუკავშიროთ mrtos.c პროექტს და ჩართოთ mrtos.h. კოდის სტრუქტურა ოდნავ განსხვავდება ჩვეულებრივიდან

#ჩართეთ #მოიცავს "mrtos.h" // აქ არის ფუნქციის ორგანო, სადაც ჩვენ ვწერთ ჩვენს სუპერ კოდსბათილი ამოცანა 1 () (ხოლო (1) // ამოცანები ნებისმიერ OS- ში აგებულია უსასრულო მარყუჟის საფუძველზე { // აქ არის თქვენი ამოცანის კოდიგაგზავნა; // განკარგვის კონტროლის გადაცემის ფუნქცია } ; } // ტაიმერის შეწყვეტის დამმუშავებელი 0შეწყვეტა [TIM0_OVF] void timer0_ovf_isr (void) (char ii; #asm ("cli") TCNT0 = 0x9C; inc_systime (); for (ii = 0; ii< init_tasks; ii++ ) if (tasks[ ii] .delay ) -- tasks[ ii] .delay ; #asm("sei") } void main(void ) { // პერიფერიული მოწყობილობების ინიციალიზაცია Init_mRTOS (); // ინიციალიზაცია os // აქ ჩვენ ვქმნით ამოცანებს (ამოცანებს) აქ იქმნება 3 ამოცანა create_task (ამოცანა 1, 1, აქტიური); // შექმენით ამოცანა (ამოცანის სახელი, პრიორიტეტი, სტატუსი) create_task (ამოცანა 2, 1, აქტიური); create_task (ამოცანა 3, 1, აქტიური); შედულერი (); // დაიწყეთ გრაფიკიხოლო (1); )

#ჩართეთ #მოიცავს "mrtos.h" // აქ არის ფუნქციის ძირითადი ნაწილი, სადაც ჩვენ ვწერთ ჩვენს სუპერ კოდს void task1 () (ხოლო (1) // ამოცანები ნებისმიერ OS- ში აგებულია უსასრულო მარყუჟის საფუძველზე (// აქ არის თქვენი ამოცანის კოდი DISPATCH; // ფუნქციის კონტროლის გადაცემა გრაფიკზე);) // ტაიმერი 0 შეწყვეტის დამმუშავებელი შეწყვეტა void timer0_ovf_isr (void) (char ii; #asm ("cli") TCNT0 = 0x9C; inc_systime (); for (ii = 0; ii)

ახლა უფრო დეტალურად. ამოცანების რაოდენობა მითითებულია mrtos.h– ში APPTASKS N. ამოცანით გამოცხადებულია ამოცანის შიგნით (1) (), ამოცანა 2 () () და ა.შ. როგორც ხედავთ, ამოცანა შედგება უსასრულო მარყუჟისგან, ეს ნორმალურია და უნდა იყოს, მაგრამ ამოცანის შიგნით აუცილებელია გრაფიკზე კონტროლის მიცემა. ან WAIT ან DISPATCH ფუნქცია. თუ ეს არ გაკეთებულა, მაშინ ამოცანა შესრულდება განუსაზღვრელი ვადით.

Როგორ მუშაობს? მოდით შევქმნათ LED მოციმციმე ამოცანა.

void task1 () (while (1) (PORTB.0 =! PORTB.0; WAIT (100););)

void task1 () (while (1) (PORTB.0 =! PORTB.0; WAIT (100););)

WAIT არის დაგვიანების () მხოლოდ ანალოგი, დაგვიანების დროს, მიკროკონტროლერი არაფერს აკეთებს და ცარიელ ციკლებს მართავს. WAIT– ის დროს კონტროლი გადადის სხვა დავალებებზე. იმ. თქვენ შეგიძლიათ შექმნათ რამოდენიმე ამოცანა სხვადასხვა LED- ების ციმციმით, განსხვავებული WAIT– ით და ისინი ყველა სხვადასხვა სიხშირით ციმციმებენ. თუ დაგვიანება არ არის საჭირო, DISPATCH გამოიყენება ბოლოს.

WAIT– ის გამოყენებისას მნიშვნელოვანია გვესმოდეს, რომ მთელ სისტემას აქვს მინიმალური შენიშვნა (დროის მონაკვეთი), ამიტომ ჩვენ არ ველოდებით WAIT (50) 50 მილიწამს, არამედ სისტემის 50 ტკიპას. ტკიპის პარამეტრი დამოკიდებულია იმაზე, თუ რამდენად ხშირად იწოდება Timer0 შეფერხება, ე.ი. თუ შეწყვეტას ვაყენებთ 1ms- ზე, მაშინ შეგვიძლია ვივარაუდოთ, რომ ჩვენი მოქმედება შესრულდება 1ms- ის ფარგლებში. ექსპერიმენტებმა აჩვენა, რომ შესაძლებელია სისტემის ტკიპის შემცირება μ 20 μs– მდე 16 MHz საათის სიხშირით.

ტაიმერის პარამეტრი არ განსხვავდება ადრე შესწავლილიდან, რადგან timer0– ს აქვს მხოლოდ გადატვირთვის შეფერხება, მაშინ ყველა პარამეტრი უკავშირდება ამას. CAVR– ის უახლეს ვერსიებში ძალიან მოსახერხებელია დროის მოთხოვნის დაწერა, პარამეტრები ავტომატურად გენერირდება.

create_task (ამოცანა 1, 1, აქტიური);

create_task (ამოცანა 1, 1, აქტიური);

პრიორიტეტებთან ერთად, ის მაინც საკმაოდ სახიფათოა. თუ არსებობს ორი განსხვავებული პრიორიტეტის ამოცანა და მუდმივად სრულდება მაღალი პრიორიტეტის მქონე ამოცანა, მაშინ ჩვენ არასოდეს შევიყვანთ ამოცანას დაბალი პრიორიტეტით. ამიტომ, თქვენ უნდა მოაწყოთ სამუშაოები ისე, რომ ყველა ამოცანამ მიიღოს წვდომა. ჩვენ ამაზე არ გავამახვილებთ ყურადღებას, ჩვენ შევინახავთ მას შემდეგ ჯერზე. ამოცანის სტატუსი, აქტიური - დაიწყო, შეაჩერა StopTask.

ასე რომ, მათთვის, ვისაც სურს მხოლოდ LED- ის დახუჭვა:

#ჩართეთ #მოიცავს "mRTOS.h" void task1 () (while (1) (WAIT (1000); PORTB.0 =! PORTB.0;)) // ტაიმერი 0 გადავსების შეწყვეტის სერვისის რუტინაშეწყვეტა [TIM0_OVF] void timer0_ovf_isr (void) (char ii; #asm ("cli") TCNT0 = 0xb2; inc_systime (); for (ii = 0; ii< init_tasks; ii++ ) if (tasks[ ii] .delay ) -- tasks[ ii] .delay ; #asm("sei") } void main(void ) { DDRB= (1 << DDB7) | (1 << DDB6) | (1 << DDB5) | (1 << DDB4) | (1 << DDB3) | (1 << DDB2) | (1 << DDB1) | (1 << DDB0) ; PORTB= (0 << PORTB7) | (0 << PORTB6) | (0 << PORTB5) | (0 << PORTB4) | (0 << PORTB3) | (0 << PORTB2) | (0 << PORTB1) | (0 << PORTB0) ; // ტაიმერი / მრიცხველი 0 ინიციალიზაცია// საათის წყარო: სისტემის საათი // საათის მნიშვნელობა: 7.813 kHz TCCR0 = (0<< CS02) | (1 << CS01) | (1 << CS00) ; TCNT0= 0x83 ; // ტაიმერი (ები) / მრიცხველი (ები) ინიციალიზაციის შეფერხება (ები) TIMSK = (0<< OCIE2) | (0 << TOIE2) | (0 << TICIE1) | (0 << OCIE1A) | (0 << OCIE1B) | (0 << TOIE1) | (1 << TOIE0) ; Init_mRTOS() ; create_task(task1, 1 , Active) ; Sheduler() ; while (1 ) ; }

#ჩართეთ #მოიცავს "mRTOS.h" void task1 () (while (1) (WAIT (1000); PORTB.0 =! PORTB.0;))) // ტაიმერი 0 overflow interrupt service rutine interrupt void timer0_ovf_isr (void) (char ii ; #asm ("cli") TCNT0 = 0xb2; inc_systime (); for (ii = 0; ii

როგორც ბონუსი, შევეცადე შემექმნა პოლიფონიური (ორხმიანი) მელოდია "დოქტორ მარიო ჩილი". იდეა იმაშია, რომ კონტროლერის თითოეული ფეხი მუდმივად გადაბრუნებულია ცალკეულ ამოცანაში, რითაც წარმოქმნის სიხშირეს. შეფერხების შეცვლით, შეგიძლიათ შეცვალოთ შენიშვნის სიმაღლე.

void task2 (void) (while (1) (if (მუნჯი == 0) // თუ ნებადართულია თამაში(თუ (note_ch2 [n_n] == 0) // თუ არის პაუზა, დაელოდე, არაფერი ითამაშო(PORTB.4 = 0; დაელოდეთ (5);) სხვაგან (PORTB.4 =! PORTB.4; // თუ პაუზა არ არის, მაშინ დაარტყა ფეხი სასურველი სიხშირითლოდინი (შენიშვნა_ჩ 2 [n_n]); )))))

ბათილი ამოცანა 2 (ბათილი) (ხოლო (1) (თუ (მუნჯი == 0) // თუ ნებადართულია თამაში (თუ (შენიშვნა_ჩ2 == 0) // თუ პაუზაა მაშინ ველოდებით, არაფერს არ ვთამაშობთ (PORTB.4 = 0; დაელოდეთ (5);) სხვაგან (PORTB.4 =! PORTB.4; // თუ არა პაუზა, მაშინ დარტყმა საჭირო სიხშირით დაელოდეთ (შენიშვნა_ჩ 2);))))

მე არ დავინტერესებულვარ იდეით, 1 ამოცანაში წარმოიქმნება მეანდერი ნოტის სიხშირით სოლო ნაწილისთვის, მეორეში ბასისთვის. თითოეული ნოტის სიმაღლე აღებულია მასივებიდან. ხანგრძლივობა, გადართვა და შეწყვეტა ამოცანაში 3.

void task3 (void) (while (1) (WAIT (1500); // ითამაშეთ შენიშვნის მინიმალური ხანგრძლივობა for (მუნჯი = 0; მუნჯი< 500 ; mute++ ) // შეწყვიტე შენიშვნა ისე, რომ ისინი არ გაერთიანდნენ(PORTB.3 = 0; PORTB.4 = 0;); მუნჯი = 0; // დააყენეთ დროშა, რომლის საშუალებითაც შეგიძლიათ ხმის დაკვრა n_n ++; // გადადით შემდეგ შენიშვნაზეთუ (n_n == n_max) // თუ ჩვენ ვითამაშეთ ყველაფერი მაშინ წრეში გადადით(n_n = 0;)))

void task3 (void) (while (1) (WAIT (1500); // დაკვრის მინიმალური შენიშვნის ხანგრძლივობა (მუნჯი = 0; მუნჯი< 500; mute++) //обрываем ноту, чтобы не сливались { PORTB.3 = 0; PORTB.4 = 0; }; mute = 0; //выставляем флаг, что можно воспроизводить звук n_n++; //переходим на следующую ноту if(n_n == n_max) //если сыграли все то идем по кругу { n_n = 0; } } }

ორი არხის დასაზავებლად გამოვიყენე მარტივი სქემა.

სულ პატარა ნაჭერი

მათთვის, ვისაც სურს firmware

მე შევიმუშავე 10-ზე მეტი ელექტრონული მოწყობილობა და მთლიანად გავათავისუფლე მათი დაბალი დონის ფუნქციონირება ოპერაციული სისტემის გარეშე. სიტუაცია შეიცვალა, როდესაც მომდევნო მოწყობილობის ფუნქციონირება მკვეთრად გაფართოვდა. გარდა ამისა, საჭიროა დავალების შესრულება, რომელსაც ეწოდება დროის განსაზღვრული ინტერვალით და ზარის სიზუსტე გავლენას ახდენს შედეგზე. ასევე გაირკვა, რომ გამოყოფილი დროის განმავლობაში შეუძლებელი იქნებოდა ყველა პროგრამული უზრუნველყოფის დაწერა და ის მოგვიანებით შეიქმნებოდა. გარკვეული ფიქრის შემდეგ მივხვდი, რომ პროექტი საჭიროებდა რეალურ დროში ოპერაციული სისტემის (RTOS ან RTOS) ჩართვას.

კომპიუტერისგან განსხვავებით, სადაც OS უფრო სისტემური რესურსებით მუშაობის ფენაა, RTOS მიკროკონტროლერისთვის ის უპირველეს ყოვლისა ამოცანების შემდგენელია, სინამდვილეში ის მთავარ როლს ასრულებს "რეალურ დროში". ამ დროისთვის ჩემთვის მნიშვნელოვანია ე.წ. "ფსევდო პარალელური" ამოცანის შესრულება. ანუ, არსებობს რამდენიმე ამოცანა ერთი და იგივე პრიორიტეტით და მნიშვნელოვანია მათ დარეკვა განსაზღვრული თანმიმდევრობით განსაზღვრული ინტერვალებით.

შემდეგი მაგალითი ნათელია: Eurobot 2011 პროექტში, სისტემაში იყო 18 პერიფერიული მოწყობილობა. 2 ელექტრონული დაფა შეიძლება გაერთიანდეს ერთში ფუნქციონალური თვალსაზრისით. მათი ღირებულება შემცირდება, მათი საიმედოობა გაიზრდება (სისტემაში კომპონენტების რაოდენობა შემცირდება) და შემთხვევაში თავისუფალი სივრცის რაოდენობა გაიზრდება. გარემოება გართულებულია იმით, რომ ამოცანების რაოდენობა პროპორციულად იზრდება და აქ თქვენ არ შეგიძლიათ OS– ის გარეშე. RTOS ასევე დაგეხმარებათ თავიდან აიცილოთ პროცესორის შესაძლო გათიშვა, მაგალითად, ADC კონვერტაციის დროს შეგიძლიათ დაბლოკოთ ეს ამოცანა და შეასრულოთ სხვები, რითაც სწორად გაანაწილეთ მოწყობილობის მუშაობა. ასევე მნიშვნელოვანია, რომ ახლა მოწყობილობა არ დაეცემა ამოცანის წარუმატებლობის გამო; სამაგიეროდ, შესაძლებელია ნაწილობრივი ფუნქციონირების შენარჩუნება (თუმცა ამან შეიძლება გამოიწვიოს არაპროგნოზირებადი შედეგები). როგორ უზრუნველვყოთ ამ ინდიკატორების ზრდა? სინამდვილეში, ჩვენ ვიღებთ ყველაფერს, რაც შესაძლებელია MK– დან, ეფექტურად ვიყენებთ მის გამოთვლილ შესაძლებლობებს.

ხანმოკლე ძებნის შემდეგ არჩევანი freeRTOS– ზე დაეცა. ეს RTOS განაწილებულია C წყაროში და გადატანილია 27 არქიტექტურაში. ბოლო გარემოება ჩემთვის გადამწყვეტია. ეს შეამცირებს შრომის ხარჯებს სხვა მწარმოებლების MCU– ებთან მუშაობისას. ახლა მე უფრო დაინტერესებული ვარ AVR პორტით.

პროექტში RTOS freeRTOS- ის არსებობა ჭამს პროგრამის მეხსიერებას დაახლოებით 9.8 KB და ოპერატიულ მეხსიერებას 1.8 KB. მაგალითად, ATmega32 და WinAVR შემდგენლებისთვის ეს არის შესაბამისად 60% და 85%. უკვე ამ მოდელისთვის ძნელია შექმნას მოწყობილობა დიდი ფუნქციონირებით - არ იქნება საკმარისი მეხსიერება. მაგრამ ეს პრობლემა ქრება ახალი AVR მოდელებით. ეს სრულიად უმნიშვნელოა Mega2560– ისთვის 256 კბ პროგრამული მეხსიერებით და 8 კბ ოპერატიული მეხსიერებით. მომავალი MC– ების ტენდენცია მხოლოდ თან ახლავს RTOS– ის წარმატებას.

Runet– ის გავლისას, გამიკვირდა, რომ აღმოვაჩინე, რომ რუსულ ენაზე არ არსებობს OS დოკუმენტაცია. Რა არის ეს! ორიგინალური დოკუმენტაცია ნაწილდება დამატებით ფასად. სიტუაცია გამარტივდა ანდრეი კურნიცის სტატიამ ( [ელფოსტა დაცულია]) ჟურნალიდან "კომპონენტები და ტექნოლოგიები". ავტორის თანხმობით, მე გამოვიყენებ სტატიის მასალებს შესწორებულ ვერსიაში. მისი სტატია შეიძლება იყოს დოკუმენტაცია რუსულ ენაზე. მაგრამ ორიგინალი არ არის ნაბეჭდი სახით, ჟურნალის საიტი ცრუობს, ასე რომ მასალის ოდნავ გადამუშავება მოუწევს. ზოგადად, ავტორს აქვს შესანიშნავი სტატია და აზრი არ აქვს თეორიის ხელახლა გადახედვას, ის სრულად გამოქვეყნდება აქ. ორიგინალური სტატია დაერთვის პუბლიკაციის ბოლოს. მე ასევე შევნიშნე, რომ მომხმარებლებს უჭირდათ RTOS– ის შედგენა. ეს გამოწვეულია იმით, რომ გამოიყენება გარე ჩანაწერი, რომელიც შეიცავს გზებს საქაღალდეებისკენ. ამიტომ, მე დავამატებ დასრულებულ პროექტს, როგორც შაბლონი AVR სტუდიისა და AVR Eclipse- ისთვის. სამწუხაროდ, მშობლიური ჩანაწერი არ გამოსცემს გამართვის ინფორმაციას, როგორიცაა ოპერატიული მეხსიერება და პროგრამის მეხსიერების გამოყენება, ეს უნდა დაფიქსირდეს შესაბამისი სტანდარტული ზარის დამატებით.

ასე რომ, მოკლედ საჭიროების შესახებ, მიზანშეწონილია გამოიყენოთ RTOS თქვენს პროექტში, საჭიროების შემთხვევაში:

მოაწყეთ მრავალმხრივი ამოცანები და ალტერნატიული ამოცანები

დარწმუნდით, რომ ამოცანა იწყება მკაცრად განსაზღვრული ინტერვალებით

ინფორმაციის გადაცემა ერთი დავალებიდან მეორეზე

დაამატეთ ახალი დავალებები საჭიროებისამებრ

RTOS- ის უპირატესობა M- სთან შედარებით TO:

1. მრავალ ამოცანა. RTOS პროგრამისტს აძლევს მზა, გამართული მრავალ ამოცანის მექანიზმს. მარტივ შემთხვევაში, თითოეული ამოცანა შეიძლება დაპროგრამდეს ცალკე, ყველა სამუშაო შეიძლება დაიყოს გუნდის რამდენიმე წევრს შორის. თქვენ არ გჭირდებათ ფიქრი ამოცანებს შორის გადართვაზე, გრაფიკი ამას გააკეთებს.
2. დროის ბაზა. დროის ინტერვალი უნდა იყოს გაზომილი. RTOS– ს უნდა ჰქონდეს ეს ინსტრუმენტი. ეს საშუალებას მოგცემთ შეასრულოთ მოქმედებები მკაცრად გამოყოფილი ინტერვალებით.
3. მონაცემთა გაცვლა დავალებებს შორის. ამისათვის RTOS იყენებს რიგს.
4. სინქრონიზაცია. თუ სხვადასხვა ამოცანები იყენებენ ერთსა და იმავე რესურსს, როგორიცაა სერიული პორტი, მაშინ შეიძლება გამოყენებულ იქნას მუნტექსები და კრიტიკული სექციები. თუ თქვენ გჭირდებათ დავალებების შესრულება მკაცრი თანმიმდევრობით ან როდესაც ხდება კონკრეტული მოვლენა, შეგიძლიათ გამოიყენოთ სემფორები ან სიგნალები ამოცანების სინქრონიზაციისათვის.

RTOS– ის უარყოფითი მხარეები:

1. ბირთვის განსახორციელებლად საჭირო პროგრამული მეხსიერების მკვეთრი ზრდა

2. საჭირო ოპერატიული მეხსიერების გაზრდა თითოეული დავალების, სემფორების, რიგების, მუტექსებისა და სისტემის ბირთვის სხვა ობიექტების შესანახად.

3. შეფერხებები ამოცანებს შორის გადართვისას კონტექსტის შესანახად.

აღწერაfreeRTOS:

FreeRTOS არის უფასო ღია კოდის მყარი რეალურ დროში OS. ძირითადად დაწერილია C, მაგრამ ასამბლერი ჩანართებია წარმოდგენილი. იგი შემუშავებულია შპს Real Time Engineers– ის მიერ სპეციალურად ჩამონტაჟებული სისტემებისთვის. ცოტა ხნის წინ, SafeRTOS პროექტის განვითარება დაიწყო - FreeRTOS– ის შეცვლილი, დოკუმენტირებული, გამოცდილი და დამოწმებული ვერსია IEC 61508 უსაფრთხოების სტანდარტის შესაბამისად. ეს პროექტი განხორციელდა გერმანული კომპანიის მიერ და ახლა safeRTOS გამოიყენება საჰაერო კოსმოსურ ინდუსტრიაში და სამედიცინო ტექნოლოგიაში. ასევე არსებობს openRTOS პროექტი - კომერციული ვერსია მწარმოებლის გარანტიით.

FreeRTOS– ის ძირითადი მახასიათებლები:

1. Scheduler მხარს უჭერს 3 ტიპის მრავალ ამოცანას:

გადაადგილება

კოოპერატივი

ჰიბრიდული

2. ბირთვის ზომა არის 9.8 KB შედგენილი AVR– სთვის. (WINAVR)

3. ბირთვის საფუძველი - 4 ფაილი C.

4. მხარს უჭერს ამოცანებსა და კოროუტინებს. კოროუტინები სპეციალურად შექმნილია მცირე მოცულობის ოპერატიული მეხსიერების მქონე MCU– ებისთვის.

5. თვალთვალის მდიდარი შესაძლებლობები.

6. შესაძლებელია თვალყური ადევნოს დასტის გადავსებას.

7. არ არსებობს პროგრამული შეზღუდვები ერთდროულად შესრულებული ამოცანების რაოდენობაზე.

8. არ არსებობს შეზღუდვა ამოცანების პრიორიტეტების რაოდენობაზე.

9. რამდენიმე ამოცანას შეიძლება მიენიჭოს ერთი და იგივე პრიორიტეტი

10. სინქრონიზაციის მოწინავე საშუალებები "ამოცანა-ამოცანა" და "ამოცანა-შეწყვეტა":

რიგები

ორობითი სემაფორები

სემიფორმების დათვლა

რეკურსიული სემფორები

მუტექსები

11. მუნტექსი პრიორიტეტული მემკვიდრეობით.

12. მეხსიერების დაცვის მოდულის მხარდაჭერა Cortex-M3– ისთვის

13. მიეწოდება გამართული ფორმით დემო პროექტებით სხვადასხვა პლატფორმებისა და შემდგენლებისათვის.

14. უფასო. შეიძლება გამოყენებულ იქნას პროექტებში წყაროს კოდის გამჟღავნების გარეშე გაფართოებული GPL ლიცენზიით.

15. დოკუმენტაცია ფასიანია, მაგრამ აქ შესაძლებელია ონლაინ რეჟიმში.

16. კონტექსტის გადართვის დრო AVR კვარცით 16 MHz იქნება მხოლოდ 20.8 μs. ეს არის ზუსტად ის, რაც საჭიროა მონაცემების შესანახად ამოცანის დასტაში და მომდევნოს დარეკვისთვის. (საინტერესო შენიშვნა, თუ ამას შეადარებთ PIC18xxx– ს, მაშინ AVR კონტროლერი მას 4 ჯერ უფრო სწრაფს ხდის !!!, სავარაუდოდ ეს განპირობებულია შემდგენლის ხარისხით)

პრევენციული მრავალმხრივი ამოცანა ნიშნავს იმას, რომ დაბალი პრიორიტეტის მქონე ამოცანა გადაფარავს დასრულებულ დავალებას უმაღლესი პრიორიტეტით. ამოცანებს შორის გადართვა ხდება თანაბარი დროის ნაჭრებად. ამრიგად, სანამ მაღალი პრიორიტეტული დავალება დაიწყებს შესრულებას, დროის მცირე მონაკვეთი, როდესაც დაბალი პრიორიტეტი შესრულებულია, უნდა დასრულდეს.

ამრიგად, FreeRTOS– ის რეაქციის დრო გარე მოვლენებზე პრევენციული მრავალ ამოცანის რეჟიმში არის არა უმეტეს გრაფიკის ერთჯერადი ნაჭერი, რომელიც შეიძლება დაყენდეს პარამეტრებში. სტანდარტულად, ეს არის 1 ms.

თუ ერთიდაიგივე პრიორიტეტის რამდენიმე დავალება მზად არის შესასრულებლად, მაშინ განლაგება თითოეულ მათგანს გამოყოფს ერთჯერად ნაჭერზე, რის შემდეგაც კონტროლი მიიღება იმავე ამოცანით იმავე პრიორიტეტით და ასე შემდეგ წრეში.

კოოპერატიული მრავალმხრივი ამოცანა განსხვავდება პრევენციული მრავალფუნქციური ამოცანისაგან იმით, რომ გრაფიკი თავად ვერ შეწყვეტს მიმდინარე ამოცანის შესრულებას, თუნდაც მაღალი პრიორიტეტის მქონე დავალებას, რომელიც მზად არის შესასრულებლად. თითოეულმა ამოცანამ დამოუკიდებლად უნდა გადასცეს კონტროლი გრაფიკზე. ამრიგად, მაღალი პრიორიტეტული ამოცანა დაელოდება დაბალ პრიორიტეტულ დავალებას, რომ დაასრულოს თავისი სამუშაო და დააბრუნოს კონტროლი გრაფიკზე. სისტემის რეაგირების დრო გარე მოვლენაზე განუსაზღვრელია და დამოკიდებულია იმაზე, თუ რამდენ ხანს შესრულდება მიმდინარე ამოცანა კონტროლის გადაცემამდე. Windows 3.x ოპერაციული სისტემების ოჯახში გამოიყენებოდა კოოპერატიული მრავალ ამოცანა.

პრევენციული და ერთობლივი მრავალმხრივი ამოცანები იკრიბებიან ჰიბრიდულ მრავალ ამოცანაში, სადაც განმსაზღვრელს ყოველ ჯერზე ეძახიან, მაგრამ წინასწარგანსაზღვრული მრავალ ამოცანისგან განსხვავებით, პროგრამისტს აქვს უნარი ამის გაკეთება იძულებით ამოცანის სხეულში. ეს რეჟიმი განსაკუთრებით სასარგებლოა, როდესაც აუცილებელია სისტემის რეაგირების დროის შემცირება შეფერხებამდე. დავუშვათ, რომ ამჟამად მიმდინარეობს დაბალი პრიორიტეტული ამოცანა და მაღალი პრიორიტეტული ამოცანა ელოდება გარკვეული შეფერხების მოხდენას. შემდეგ ხდება შეფერხება, მაგრამ შეწყვეტის დამმუშავებლის ბოლოს შესრულება უბრუნდება მიმდინარე დაბალ პრიორიტეტულ ამოცანას და მაღალი პრიორიტეტი ელოდება მიმდინარე დროის მონაკვეთის დასრულებამდე. თუმცა, თუ შეფერხების დამმუშავებლის შესრულების შემდეგ კონტროლი გადადის გრაფიკზე, მაშინ ის გადასცემს კონტროლს პრიორიტეტულ ამოცანას, რაც ამცირებს სისტემის რეაგირების დროს, რომელიც დაკავშირებულია გარე მოვლენასთან.

რატომზესასაუბრობ?

თქვენ შეგიძლიათ დაიწყოთ მიკროკონტროლის მოწყობილობის განვითარება FreeRTOS– ით, მისი უახლესი ვერსიის გადმოტვირთვით.

FreeRTOS განაწილება ხელმისაწვდომია როგორც რეგულარული ან თვითმოპოვებული ZIP არქივი. განაწილება შეიცავს ბირთვის კოდს (რამდენიმე სათაურისა და წყაროს ფაილის სახით) და დემო პროექტებს (თითო პროექტს თითოეული განვითარების გარემოსთვის თითოეული პორტისთვის). შემდეგი, თქვენ უნდა გახსნათ არქივი განვითარების სადგურის ნებისმიერ შესაფერის ადგილას.

არქივში ფაილების დიდი რაოდენობის მიუხედავად, დირექტორიის სტრუქტურა ფაქტობრივად მარტივია. თუ თქვენ გეგმავთ მოწყობილობების შექმნას 2-3 არქიტექტურაზე 1-2 განვითარების გარემოში, მაშინ დემო პროექტებთან და განვითარების სხვადასხვა გარემოსთან დაკავშირებული ფაილების უმეტესობა არ იქნება საჭირო.

დეტალური დირექტორიის სტრუქტურა ნაჩვენებია დიაგრამაში.

ყველა ბირთვის წყარო მდებარეობს / Source დირექტორიაში.

შინაარსი:

1. ამოცანები. გ- ამოცანის მექანიზმის დანერგვა, გრაფიკი

2. რიგი.გ- რიგების განხორციელება

3. სია.გ- გრაფიკის შიდა საჭიროებები, მაგრამ ფუნქციები ასევე შეიძლება გამოყენებულ იქნას პროგრამულ პროგრამებში.

4. კრუტინი.გ- კოროუტინის განხორციელება (შეიძლება არ არსებობდეს, თუ კოროუტინები არ გამოიყენება).

სათაურის ფაილები, რომლებიც დირექტორია წყარო / ჩართვა

1. ამოცანები. საათი, რიგი- სათაურის ფაილები, შესაბამისად, კოდის მქონე ამავე სახელწოდების ფაილებისთვის.

2. FreeRTOS.h-შეიცავს კომპლექტაციის კონფიგურაციის წინასწარი დამუშავების დირექტივებს.

3.mpu_wrappers.h- შეიცავს FreeRTOS პროგრამირების ინტერფეისის (API) ფუნქციების უგულებელყოფას მეხსიერების დაცვის მოდულის (MPU) მხარდასაჭერად.

4. პორტატული. თ-პლატფორმაზე დამოკიდებული პარამეტრები.

5.პროდეფს.ს-ზოგიერთი სისტემის განმარტება

6. სემფრ.ჰ- განსაზღვრავს API ფუნქციებს სემფორებთან მუშაობისთვის, რომლებიც ხორციელდება რიგების საფუძველზე.

7. StackMacros.h- შეიცავს მაკროებს დასტის გადავსების გასაკონტროლებლად. თითოეული აპარატურის პლატფორმა მოითხოვს ბირთვის კოდის მცირე ნაწილს, რომელიც ახორციელებს FreeRTOS– ის თავსებადობას ამ პლატფორმასთან. ყველა პლატფორმის სპეციფიკური კოდი არის ქვე დირექტორიაში / წყარო / პორტატული, სადაც ის დაყოფილია განვითარების გარემოს (IAR, GCC და ა.შ.) და ტექნიკური პლატფორმების მიხედვით (მაგალითად, AtmelSAM7S64, MSP430F449). მაგალითად, ქვედირექტორია / წყარო / პორტატული / GCC / ATMega323შეიცავს ფაილებს port.c და portmacro.h, რომლებიც ახორციელებენ ამოცანის კონტექსტის დაზოგვას / აღდგენას, ტაიმერის ინიციალიზაციას დროის ბაზის შესაქმნელად, თითოეული ამოცანის დასტის ინიციალიზაციას და სხვა ტექნიკაზე დამოკიდებულ ფუნქციებს მეგა AVR ოჯახის მიკროკონტროლერებისთვის და WinAVR შემდგენელი (GCC).

ცალკე, თქვენ უნდა გამოყოთ ქვედირექტორია / წყარო / პორტატული / MemMangრომელიც შეიცავს ფაილებს heap_l.c, heap_2.c, heap_3.cრომლებიც ახორციელებენ მეხსიერების გამოყოფის 3 განსხვავებულ მექანიზმს FreeRTOS– ის საჭიროებებისთვის, რომელიც შემდგომში დეტალურად იქნება აღწერილი.

/ დემო დირექტორია შეიცავს მზა დემო პროექტების შესადგენად და შესაქმნელად. ყველა დემო პროექტის კოდის საერთო ნაწილი ხაზგასმულია ქვედირექტორიაში / დემო / კომო n

თქვენს პროექტში FreeRTOS გამოსაყენებლად, თქვენ უნდა შეიცავდეთ ბირთვის წყაროს ფაილებს და მათთან დაკავშირებულ სათაურის ფაილებს. არ არის საჭირო მათი შეცვლა ან მათი განხორციელების გაგება.

მაგალითად, თუ თქვენ აპირებთ პორტის გამოყენებას MSP430 მიკროკონტროლერებისთვის და GCC შემდგენლისთვის, მაშინ ნულიდან პროექტის შესაქმნელად "დაგჭირდებათ ქვე დირექტორიები / წყარო / პორტატული / GCC / MSP430_GCCდა / წყარო / პორტატული / MemMang... ყველა სხვა ქვე დირექტორიები / წყარო / პორტატული დირექტორია არასაჭიროა და მათი ამოღება შესაძლებელია.

თუ თქვენ აპირებთ არსებული დემო პროექტის შეცვლას (რაც, ფაქტობრივად, რეკომენდებულია FreeRTOS კვლევის დასაწყისში), მაშინ ასევე დაგჭირდებათ ქვე დირექტორიები / დემო / msp430_GCCდა / დემო / საერთო... დანარჩენი / დემო ქვე დირექტორიები არასაჭიროა და მათი ამოღება შესაძლებელია.

პროგრამის შექმნისას რეკომენდებულია მისი გამოყენება მაკიაჟი(ან განვითარების გარემოს პროექტის ფაილი) შესაბამისი დემო პროექტიდან, როგორც ამოსავალი წერტილი. მიზანშეწონილია გამორიცხოთ build (build) ფაილები / Demo დირექტორიიდან, შეცვალოთ ისინი თქვენით და ფაილები / Source დირექტორია - ხელუხლებელი. სათაურის ფაილი ასევე უნდა აღინიშნოს FreeRTOSConfig.hრომელიც ყველა დემო პროექტშია. FreeRTOSConfig.h შეიცავს განმარტებებს (#define), რომელიც იძლევა FreeRTOS ბირთვის კონფიგურაციის საშუალებას:

1. სისტემის ფუნქციების ერთობლიობა.

2. კოროტინების გამოყენება.

3. ამოცანებისა და კოროუტინების პრიორიტეტების რაოდენობა

4. მეხსიერების ზომები (დასტა და გროვა).

5. MK სიხშირე MK.

6. თითოეული შემსრულებელი ამოცანისათვის გამოყოფილი დროის განმსაზღვრელის პერიოდი, რომელიც ჩვეულებრივ არის 1 ms. გამორთეთ სისტემის ზოგიერთი ფუნქცია და შეამცირეთ პრიორიტეტების რაოდენობა (ამცირებს მეხსიერების მოხმარებას).

FreeRTOS დისტრიბუცია ასევე მოიცავს ინსტრუმენტებს გრაფიკიდან მიღებული კვალი ინფორმაციის ტექსტურ ფორმად (დირექტორია / TgaseCon) და ლიცენზიის ტექსტი (დირექტორია / ლიცენზია).

დასკვნები

სერიის პირველი სტატიის დახმარებით მკითხველი გაეცნო FreeRTOS მიკროკონტროლერების ოპერაციულ სისტემას. ნაჩვენებია სამუშაოს მახასიათებლები. აღწერეთ FreeRTOS განაწილების შინაარსი. მოცემულია ძირითადი ნაბიჯები FreeRTOS– ით გაშვებული მოწყობილობის შემუშავების დასაწყებად.

მომავალ პუბლიკაციებში ყურადღება გამახვილდება მრავალ ამოცანის მექანიზმზე, კერძოდ ამოცანებზე და კოროუტინებზე. გრაფიკის მაგალითი ნაჩვენები იქნება Atmel AVR მიკროკონტროლერების და WinAVR შემდგენლის (GCC) მაგალითის გამოყენებით.

მე მუდმივად ვსვამ ამ კითხვას, როდესაც ვაკეთებ ჩემს ჰობს - სახლის ავტომატური მართვის სისტემის (ჭკვიანი სახლის) შემუშავებას 16 ბიტიანი მიკროკონტროლერის საფუძველზე - ეს ნამდვილად სწორი მიდგომაა? თვენახევრის წინ, მე უკვე დავწერე ჩემს ბლოგში თემაზე "მიკროკონტროლერები სისტემებზე-ჩიპზე". ასე რომ, მე ვაპირებ კიდევ ერთხელ დავწერო ამის შესახებ.

ნაწილობრივ, მე მოტივირებული ვიყავი Stellaris Launchpad და Arduino Due გამოშვებით. ისინი ორივე დაფუძნებულია 32 ბიტიან მიკროკონტროლერებზე და ძალიან ჰგვანან მრავალი თვალსაზრისით. მე შევისწავლე მონაცემთა ცხრილი ორივესთვის და მიუხედავად იმისა, რომ ისინი ფასში საკმაოდ განსხვავდებიან, ისინი განკუთვნილია ერთი და იგივე სამიზნე აუდიტორიისთვის. ვიფიქრე, რომ იქნებ MSP430– დან გადავიდე Stellaris– ზე, ან იქნებ ფუნდამენტურად განსხვავებულ სისტემაზე გადავიდე, მიკროკონტროლერების ნაცვლად გამოვიყენო რაღაც ჟოლოს პი.

Stellaris Launchpad და Arduino Due ძალიან ძლიერია, მაგრამ არ არის შექმნილი Linux– ის გასაშვებად. ისინი მუშაობენ ან მათზე პირდაპირ დაწერილ შესრულებად კოდზე, ან რეალურ დროში ოპერაციული სისტემის (RTOS) კონტროლის ქვეშ, მინიმალისტური ოპერაციული სისტემით, გარე მოვლენებზე ძალიან მოკლე რეაგირების დროით. ისინი ორივე ბევრად უფრო რთულია, ვიდრე MSP430 ან 8 ბიტიანი AVR.

მეორეს მხრივ, რეალურ ცხოვრებაში (ინტერნეტის გარეთ), ჩემი ნაცნობი ადამიანების უმეტესობა იყენებს Raspberry Pi- ს ან სხვა ჩაშენებულ Linux სისტემებს. მიკროკონტროლერების გამოყენება საკმაოდ იშვიათი შემთხვევაა მათ შორის, ვისაც შევხვედრივარ. მაშინაც კი, Arduino გაცილებით ნაკლებად პოპულარულია ჩემს გარემოში, ვიდრე ჩაშენებული Linux. როგორც მესმის, რატომ ყიდულობს ვინმე Arduino- ს, როდესაც თქვენ შეგიძლიათ შეიძინოთ Raspberry Pi, რომელსაც გაცილებით მეტის გაკეთება შეუძლია, მაგრამ იგივე ან ნაკლები ღირს? არსებობს უზარმაზარი მზა პროგრამული უზრუნველყოფა Linux– ისთვის და თქვენ შეგიძლიათ მისი დაპროგრამება მარტივი სკრიპტირების ენების გამოყენებით.

პირადად ჩემთვის, მიზეზი იმისა, რომ არ მინდა Linux– ის გამოყენება, არის ის, რომ მას ვიყენებ ყოველდღე სამსახურში და როდესაც სახლში ვბრუნდები, არ მსიამოვნებს, რომ ისევ Linux– ის მსგავს სისტემებზე უნდა ვიმუშაო. მე Linux– ის გამოყენების პრობლემა არ მაქვს, მაგრამ ის ძალიან ბევრია ყველგან, ის მე ამძიმებს. ჩემთვის ბევრად უფრო საინტერესოა მარტივი ელექტრონული მოწყობილობებით მუშაობა 8/16-ბიტიანი მიკროჩიპებით.

თუმცა, მე რეალობას ზურგს არ ვაქცევ. თუ მსურს ვიყო რეალურ სამყაროსთან შესაბამისობაში, უნდა გამოვიყენო ის ინსტრუმენტები, რომლებიც რეალურ სამყაროში გამოიყენება. წინააღმდეგ შემთხვევაში, ეს იგივეა, რომ სურდეს ავტომობილის მართვა ორთქლის ძრავით, მხოლოდ იმიტომ, რომ შიდა წვის ძრავა ძალიან ამქვეყნიურია, ამიტომ მე მას ყოველთვის ვიყენებ. თუ სამყარო ჩვენს გარშემო უფრო მოწინავე ტექნოლოგიაზე გადადის, აუცილებელია მისი დაუფლება, მომწონს თუ არა ეს. მით უმეტეს, თუ მინდა, რომ ჩემი ბლოგი იყოს საინტერესო ადამიანებისთვის და იყოს შესაბამისი.

ჩემი ჭკვიანი სახლის პროექტში მე რეალურად შევეჯახე ამ პრობლემას. მე უკვე გავაკეთე LAN დრაივერი კონტროლის სისტემისთვის MSP430 და ყველაფერი ძალიან ღირსეულად გამოიყურება. ძირითადად, მე შემიძლია გავაკეთო ის, რაც საჭიროა MSP430 ავტომატიზაციის სისტემისთვის. თუმცა, მაინტერესებს, სწორია თუ არა ის, რასაც ვაკეთებ? ვცდილობ თუ არა კოვზით სუპის ჭამა ჩანგლით? იქნებ Linux არის უკეთესი სისტემა? Ნება მომეცი აგიხსნა.

თუ გავჩერდებით და შევხედავთ არსებულ სიტუაციას, 2012 წლის ნოემბრის ტექნოლოგიური მიღწევების თვალსაზრისით. მე ვეკითხები ჩემს თავს, არიან თუ არა მიკროკონტროლერები საკმარისად კარგი და შესაბამისი Linux– ის გამოყენებით ჩიპურ სისტემებთან შედარებით?

თუ ჩამოთვლი პროექტებს ჩამონტაჟებული სისტემების შესახებ, რაც ჩემს გონებაში მოდის, ესენია: თვითმფრინავები, რობოტები, სახლის ავტომატიზაცია, საავტომობილო კონტროლერები, სენსორები, მაჯის საათები, 3D პრინტერები და ა. ამ შემთხვევებში რომელია Linux უფრო მიზანშეწონილი ვიდრე მიკროკონტროლერები? Და რატომ?

მე მჯერა, რომ არსებობს სამი სიტუაცია, როდესაც მიკროკონტროლერი არის საუკეთესო არჩევანი: სადაც მოვლენებზე მყისიერი (რეალურ დროში) რეაგირება მნიშვნელოვანია; სადაც საჭიროა ენერგიის უკიდურესად დაბალი მოხმარება; და სადაც თქვენ უნდა გამოიყენოთ ჩიპები ყველაზე დაბალი ღირებულებით.

დასაწყისისთვის, იაფი მიკროცირკების გამოყენება ჩემთვის არც ისე მნიშვნელოვანია. მე ვაკეთებ ჩემს ჰობის თავს და არ ვაპირებ კონკურენტუნარიანი პროდუქტების გამოშვებას. მე არ უნდა ვიფიქრო მონების შრომის ქარხანაში პროდუქციის გადატანაზე, რომ კონკურენტუნარიანი ფასი შევიქმნა ჩემს მიერ შემუშავებული მცირე პროექტებისთვის. მოხარული ვიქნები, თუ ჩემი შესაძლებლობების წყალობით შევძლებ დღეში ერთზე მეტ დაფაზე შეკვრას!

მაგალითად, ჭკვიანი სახლის პროექტისთვის შემიძლია დისტანციურად კონტროლირებადი გადამრთველის დიზაინი. მას შეუძლია განათების ჩართვა / გამორთვა ან სხვა რამ. ამავდროულად, შემიძლია წავიდე ჩემს ადგილობრივ ელექტრო მაღაზიაში და იგივე ვიყიდო 20 დოლარად, დამზადებულია ჩინეთში. ოდესმე დავამარცხებ ამ ფასს საკუთარი ჩამრთველის გაყიდვის მცდელობით? არ მგონია შესაძლებელი.

თუ დაფიქრდებით, ეს ასევე ეხება ბევრ სხვა რამეს, რაც საჭიროა სახლის ავტომატიზაციისთვის. სენსორები ტემპერატურის, კვამლის, მოძრაობის და ა.შ. ვის აინტერესებს ჩემგან ასეთი ნივთების ყიდვა 75 დოლარად, როდესაც მათ შეუძლიათ 20 დოლარად იპოვონ საყოფაცხოვრებო პროდუქტები?

თუ თქვენ ფიქრობთ თქვენი ჰობიდან რაიმე სარგებლის მიღებაზე, მაშინ უმჯობესია ყურადღება მიაქციოთ უფრო ძვირადღირებულ და რთულ პროდუქტებს. მაგალითად, სახლის ავტომატიზაციის კონტროლერი ან თერმოსტატი, როგორც წესი, 100 დოლარზე მეტი ღირს და ინდივიდუალურ შემოქმედებას უფრო მეტ თავისუფლებას უტოვებს, შეგიძლიათ ააშენოთ ის, გაყიდოთ მეზობლებს და ფულის გამომუშავებაც კი.

მაგრამ საბოლოო მოწყობილობის უკეთესი ფასის მიღების სურვილი არ ნიშნავს იმას, რომ თქვენ უნდა გამოიყენოთ დედამიწაზე ყველაზე იაფი მიკროკონტროლი. სინამდვილეში, ეს ცუდი იდეაა, რადგან განვითარების დრო აქვს იგივე ღირებულება, როგორც გამოყენებული ნაწილები. მიკროკონტროლი შეიძლება იყოს იაფი, მაგრამ საკონტროლო კოდის წერას მეტი დრო სჭირდება. დრო არის ფული და თუ უფრო სწრაფად მუშაობ, მეტის მიღწევა შეგიძლია.

ყველა ამ მოსაზრებამ მიმიყვანა იმ დასკვნამდე, რომ უფრო მომგებიანია Linux– ზე ჭკვიანი სახლის სისტემის განვითარება ვიდრე მიკროკონტროლერებზე, ჩემი პირადი უპირატესობის მიუხედავად, არ გამოვიყენო Linux (მე მომწონს დაბალი დონის პროგრამირება სკრიპტებზე მეტად, Linux მომბეზრებს) .

დავუბრუნდეთ თემის თემას, მიკროკონტროლერების ფასს, ეს შეიძლება იყოს მნიშვნელოვანი ფაქტორი მსხვილი კორპორაციებისთვის, რომლებიც აპირებენ ახალი პროდუქტის გამოშვებას, მაგრამ ინდივიდუალურ დონეზე, თუ თქვენ ცდილობთ აწარმოოთ ბიზნესი Kickstarter სტილში, ეს ფაქტორი არც ისე მნიშვნელოვანია, ფაქტობრივად, სწრაფი განვითარების დრო, უფრო მნიშვნელოვანი ვიდრე კომპონენტების ღირებულება.

მეორეს მხრივ, მიკროკონტროლერები შეიძლება იყოს უკეთესი არჩევანი, ვიდრე სისტემები ჩიპზე, როდესაც საჭიროა დაბალი ენერგიის მოხმარება. ასეთ სისტემებში არის ორი წერტილი: წრედის დაბალი მოხმარება, ოპერაციის დროს და მოკლე დაწყების დრო. ბატარეის დაზოგვის ტიპიური მეთოდი მცირე მოწყობილობებისთვის არის გამორთვა. როდესაც გათიშავთ თქვენს Linux კომპიუტერს, სამსახურში დასაბრუნებლად ღირს საკმარისი დრო, ზოგჯერ რამდენიმე წუთამდე. ეს დრო მიუღებელია ჩაშენებული სისტემებისთვის.

თუ თქვენ იღებთ მიკროკონტროლერს, როგორიცაა MSP430, მას შეუძლია წლების განმავლობაში იმუშაოს ერთ ბატარეაზე. Stellaris Launchpad და Arduino Due, პრინციპში, შეუძლიათ ამის გაკეთება, ისინი მოიხმარენ მეტ ენერგიას, ვიდრე MSP430, მაგრამ მაინც ძალიან ცოტაა Raspberry Pi– სთან შედარებით. ასევე, MSP430 შეიძლება დაუყოვნებლივ დაიწყოს გამორთვის შემდეგ.

ამრიგად, მე აბსოლუტურად დარწმუნებული ვარ, რომ ყველა სიტუაციაში, სადაც საჭიროა დაბალი ძაბვის ოპერაციები, აზრი აქვს მიკროკონტროლერების გამოყენებას. არსებობს ბატარეაზე მომუშავე მოწყობილობების ფართო სპექტრი, სადაც ამის საჭიროება ჩნდება.

მესამე შემთხვევაში, როგორც უკვე ვთქვი, მიკროკონტროლერის გამოყენება უფრო მნიშვნელოვანია ვიდრე Linux, ოპერაციებში, რომლებიც საჭიროებენ მყისიერ რეაგირებას (რეალურ დროში რეაგირება). ვგულისხმობ მოწყობილობებს, როგორიცაა 3D პრინტერები და CNC მანქანები, მე ვიცი რაზე ვსაუბრობ მას შემდეგ, რაც მათ შესწავლას დიდი დრო დავუთმე. მათი ბუნებით, ისინი მოითხოვენ სამუშაოს მაღალ სიზუსტეს, რაც ოდნავ ნაკლებია ვიდრე მთლიანად ბრძანებებზე რეაგირების დროზე.

მაგალითად, თუ თქვენ მართავთ წრიულ ხერხს, რომელიც ამჟამად ჭრის ხის ან ლითონის ნაჭერს, თქვენ ვერ შეაჩერებთ პროცესს, იმის გამო, რომ კომპიუტერს, რომელიც მას აკონტროლებს, სჭირდება პაუზა მეხსიერებიდან დისკზე მონაცემების გადასატანად ან სხვაგვარად იგივე სულისკვეთებით. ყველას, ვინც გამოიყენა კომპიუტერი, იცნობს შემთხვევით გაყინვას, რომელიც ხდება წყვეტილი ნორმალური გამოყენების დროს. ახლა წარმოიდგინეთ, რომ თქვენ გაქვთ დიდი საბურღი მანქანა, რომელსაც აქვს კომპიუტერი, რომელიც მოულოდნელად იწყებს Windows– ის განახლებების შემოწმებას მუშაობის დროს და საბურღი ბურღავს იმ მაგიდასთან, რომელზეც ის დგას, რადგან კომპიუტერმა დაკარგა კონტროლი მასზე.

კომპიუტერები და სისტემები ჩიპზე არ არის შექმნილი რეალურ დროში მუშაობისთვის, თუნდაც Windows– ით, თუნდაც Linux– ით, მაგრამ რა თქმა უნდა ისინი ცდილობენ მიუახლოვდნენ ამას. მაგალითად, არსებობს რეალურ დროში პატჩი Linux ბირთვისთვის და სპეციალური CNC პროგრამული უზრუნველყოფა, რომელიც შექმნილია ამ სახის სამუშაოს შესასრულებლად. მე საკმარისად არ ვიცნობ Linux– ის ამ პატჩს, რომ ვიცოდე რამდენად მოქნილია რეალურ დროში მოვლენების სრულად გაკონტროლება. მაგრამ მე ვფიქრობ, რომ ეს მხოლოდ შესაძლო ალტერნატივაა, ვინაიდან Linux, რაც არ უნდა იყოს მასზე დაკიდებული, არასოდეს დაამარცხებს ამ სფეროში მიკროკონტროლებს, მათი შეწყვეტის სისტემის წყალობით.
დასასრულს, მინდა ვთქვა, რომ ბევრი დრო გავატარე იმ სფეროების პოვნაში, სადაც უპირატესობა მიენიჭა მიკროკონტროლერების გამოყენებას ჩემს პროექტებში. როგორც ჩანს, ჟოლოს Pi და Beaglebones– ის მსოფლიო ბატონობის ხანა დადგა. ეს არის ამჟამინდელი მდგომარეობა წვრილმანი საზოგადოებაში. უმეტეს შემთხვევაში, ამ სისტემებზე განვითარება უფრო სწრაფი და ადვილია, ამიტომ ხშირად საუკეთესო არჩევანია პროექტების უმეტესობისთვის.

მიკროკონტროლერებისთვის რჩება მხოლოდ დაბალი ძაბვის მოწყობილობების, რეალურ დროში ოპერაციების და დაბალფასიანი მოწყობილობების არეები.

ეს არ არის დამოკიდებული იმაზე, რომ მიკროკონტროლერები შეიძლება "უფრო სახალისო" ჩანდეს ვიდრე კომპიუტერები. ეს არის ის, რასაც უნდა შეეგუო.

ინგლისურიდან თარგმნა ორიგინალური პოსტი