Programowania systemów wbudowanych w języku C# pod .NET Micro Framework

0

Od pewnego czasu zauważyłem zainteresowanie tematyką programowania mikrokontrolerów i mikroprocesorów ARM w języku C# z wykorzystaniem platformy .NETMF będącej córką słynnej platformy Microsoft .NET Framework, którą zna chyba każdy. Niedawno wpadła mi do rąk nowa książka wydawnictwa BTC na ten temat. Zauważyłem wiele nowych zestawów uruchomieniowych dedykowanych na tą platformę, więc postanowiłem wprowadzić Was w szczegóły.

Czym jest .NET Micro Framework?

Założenia .NETMF (.NET Micro Framework) są takie same jak matki .NET. Ma umożliwiać pisanie programów na bardzo wysokim poziomie abstrakcji w języku obiektowym, ma być łatwo przenośna na dowolne platformy sprzętowe oraz ma być uniwersalna. Dodatkową zaletą samej platformy .NETMF jest możliwość bardzo proste oprogramowywania dość złożonych zadań poprzez możliwość wykorzystania bibliotek wbudowanych (mam tu na myśli obsługę kolorowego wyświetlacza TFT w sposób równie łatwy jak w Bascomie). Z powyższego opisu można odnieść podobieństwo omawianej platformy do systemu operacyjnego Linux. Wniosek taki jest w pewnym sensie racjonalny, ale platforma .NETMF nie jest pochodną systemu operacyjnego, ponieważ posiada dużo prostszy sposób dostępu do sprzętu, nie wymaga tak dużej liczby zasobów, dlatego można ją zaklasyfikować pomiędzy pisaniem programów w języku C a pisaniem programów pod linuksem. Wspomniałem jeszcze wcześniej o analogii do Bascoma. Myślę, że dużo z Was pisało lub dalej pisze w nim swoje programy. Niewątpliwą zaletą jest fakt, że posiada dużo zaimplementowanych bibliotek umożliwiających prostą obsługę peryferii. Tak samo jest również tutaj, dlatego wielu z fanów Bascoma z pewnością powinno zainteresować się tematyką. Fani programowania w języku C nie będą mieć praktycznie żadnego kłopotu z pisaniem programów w C# ponieważ bazuje on składnio na języku C (pomijając aspekty programowania obiektowego). Tak jak już wielokrotnie wspominałem C# jest językiem obiektowym, dzięki czemu umożliwia znacznie lepsze wykorzystanie czasu pisania aplikacji jak również umożliwia znacznie lepsze panowanie nad zaawansowanymi programami (nie mam tu na myśli programu posiadającego dużą liczbę linijek a raczej trudność samej koncepcji, którą wykonuje). Jeśli mowa o realizacji złożonych zadań w bardzo prostu i przyjemny sposób przedstawię pewien przykład. Każdy z Was oprogramowywał pewnie alfanumeryczny wyświetlacz LCD, dla programistów Bascomowych była to rzecz trywialna, jednak do programistów C trzeba było trochę przesiedzieć nad stworzeniem biblioteki. Proszę zauważyć, że jest to tylko zwykły wyświetlacz alfanumeryczny, na którym można przedstawić kilkanaście znaków w jednym kolorze. Idąc dalej można pokusić się o obsługę wyświetlacza graficznego LCD. Robi się już trochę gorzej. Bascomowcy nadal posiadają gotowe biblioteki jednak są już ograniczone tylko do kilku sterowników a cała zabawa staje się nieco trudniejsza. A teraz spróbujmy wyobrazić sobie oprogramowanie wyświetlacza kolorowego TFT. Z pewnością dużo osób (nie umniejszając niczyich zdolności) powie, że jest to prawie niemożliwe z poziomu AVR a jeśli już nawet to jest to bardzo trudne. W tym momencie dla porównania pokażę Wam prosty przykład jak łatwo można oprogramować wyświetlacz TFT pod platformą .NETMF.

using System;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using Microsoft.SPOT.Presentation;
using Microsoft.SPOT.Presentation.Media;
using Microsoft.SPOT.Input;
using STM32F429I_Discovery.Netmf.Hardware;
 
namespace MFPrzykladLCD
{
    public class Program
    {
        public static void Main()
        {
            Bitmap Background = new Bitmap(SystemMetrics.ScreenWidth, SystemMetrics.ScreenHeight);
            Bitmap Image = new Bitmap(Resources.GetBytes(Resources.BinaryResources.Image01), Bitmap.BitmapImageType.Bmp);
            Color Color_Red = ColorUtility.ColorFromRGB(255,0,0); 
            Background.DrawRectangle(Color.White, 0, 0, 0, 239, 319, 0, 0, Color.White, 0, 0, Color.White, 0,0, Bitmap.OpacityOpaque);
            Background.DrawLine(Color_Red, 3, 0, 0, 239, 0);
            Background.DrawLine(Color_Red, 3, 239, 0, 239, 319);
            Background.DrawLine(Color_Red, 3, 239, 319, 0, 319);
            Background.DrawLine(Color_Red, 3, 0, 319, 0, 0);
            Background.DrawImage(20, 60, Image, 0, 0, 200, 200);
            Background.Flush();
            while (true)
            {    
            }
        }
    }
}

Jak łatwo zauważyć program zawiera raptem 20 linijek kodu a wyświetla na kolorowym wyświetlaczu kolorowy obraz oraz rysuje linie. Dodatkowo w prosty sposób można dodać tekst za pomocą kilku dodatkowych linijek kodu. Napisany program można łatwo przenieść na dowolny procesor posiadający odpowiedni rozmiar pamięci Flash oraz RAM montując wcześniej obraz platformy .NETMF. Oczywiście każdy zestaw, który można kupić ma już zmontowany obraz platformy, który wystarczy tylko wgrać do układu. Może to być mikrokontroler STM32 a może to być ARM7 lub ARM9. Dodatkowo może to być produkt firmy STmicroelectronics, NXP czy Atmel. Jesteśmy w pełni zwolnieni z konieczności znania szczegółowej architektury danego procesora, wystarczy wiedzieć, co zawiera.

Zalety i ograniczenia

Pewnie wiele z Was pomyśli sobie: „tak fajnie nie może być pewnie jest w tym jakiś haczyk”. Owszem żadne rozwiązanie nie jest pozbawione ograniczeń tak samo jest z .NETMF dla procesorów. Na przykład w przypadku, kiedy zakupimy mikrokontroler, wlutujemy układu w zaprojektowany układ i chcemy uruchomić .NETMF możemy napotkać pewien problem a mianowicie musimy ręcznie dokonać montowania platformy pod ten mikrokontroler. Takie utrudnienie nigdy nie spotka nas wykorzystując gotowy zestaw uruchomieniowy. Jeśli pomyślimy o tym dłużej to co nazwałem utrudnieniem nie jest nim wcale, ponieważ istnieją specjalne moduły tzw. SOM, które zawierając w swej strukturze mikrokontroler z dodatkową pamięcią RAM lub/ i FLASH i często jeszcze dodatkowo jakimś sprzętowym rozwiązaniem. W tą myśl lepiej kupić moduł SOM (który wygląda jak moduł Bluetooth) za nieduże pieniądze, na którym mamy wszystko zaprojektowanie wraz z przygotowanym montażem platformy niż bawieniem się w ręczne projektowanie systemu. Od lewej G120E od prawej G400-S firmy GHIelectronics.

user image
user image

Oczywiście warto jeszcze wspomnieć, że wybierając tworzenie oprogramowania w .NETMF nie mamy już pełnej kontroli nad sprzętem, program jest z pewnością nieco wolniejszy kosztem łatwej obsługi wielowątkowości i pełną przenośnością.

Poniżej przedstawiam zdjęcia kilku zestawów, które można kupić i zacząć przygodę z .NETMF. Kolejno 32F429IDISCOVERY, FEZ Panda III, G400 Development Bard.

user image
user image
user image

Dodatkowo pragnę powiedzieć, że równolegle z rozwojem Arduino rozwija się Netduino, które jest mniej popularne w naszym kraju, ale myślę, że z czasem stanie się tak samo popularne. Netduino wykorzystuje właśnie platformę .NETMF a dodatkowo posiada swoje dodatkowe biblioteki.

Skąd czerpać wiedzę?

Tak jak już wspomniałem zaprezentowany przykład pochodzi z nowej polskiej książki pt. Podstawy .NET Micro Framework dla mikrokontrolerów STM32 w języku C# wydawnictwa BTC.

user image

Książka omawia pełną ideę wykorzystania .NETMF dla procesorów, wyjaśnia ideę programowania obiektowego, zawiera cały rozdział poświęcony językowi C#, dzięki czemu nie trzeba dodatkowo korzystać z innych. Wykorzystane przykłady są przedstawione na mikrokontrolerach STM32 (będących obecnie najtańszym i najkorzystniejszym rozwiązaniem) a konkretnie zestawie STM32F429IDISCOVERY zawierającym kolorowy wyświetlacz TFT. Pewnie niektórzy z Was posiadają ten zestaw, można go kupić za ponad 100zł. W książce można znaleźć wiele ciekawych aplikacji napisanych pod .NETMF omówionych bardzo praktycznie bez niepotrzebnego lania wody i wywodach teoretycznych. Choć przykłady są napisane pod mikrokontrolery STM32 można je spokojnie przenieść na każdą inną platformę sprzętową.

Istnieje również anglojęzyczna książka Getting Started with .NET Gadgeteer. Jest z kolei nastawiona na zestawy Netduino w naszym kraju ciągle stosunkowo drogie.

user image

Dodatkowo można znaleźć sporo informacji w supporcie Microsoft i na zagranicznych forach, jednak w języku angielskim.

Podsumowanie

Reasumując chciałem naświetlić ideę, programowania procesorów w .NETMF, przedstawić zalety i ograniczenia takiego podejścia oraz pomóc Wam zacząć swoją przygodę .NETMF. Na pewno nie ma sensu ładować dużego procesora, aby migać diodami, ale w momencie, kiedy chcemy wykorzystać wyświetlacz graficzny lub potrzebujemy większej mocy obliczeniowej i zasobów a przy okazji uprościć własną pracę (lub uczynić ją bardziej wydajną i przyjemniejszą) warto wziąć pod uwagę takie rozwiązanie. Myślę, że wbudowanie takiego modułu do robota jest ciekawym podejściem. Nie ma też żadnych ograniczeń by zostawić sobie drugi mikrokontroler, który będzie obsługiwał podstawowe peryferia robota i komunikował się z głównym procesorem.

1

Muszę stwierdzić, że nie do końca wiem, co zrobić z tym postem. Jaki on ma cel? Na 4programmers.net posiadamy dział "Artykuły" (C# i .NET), w którym można coś takiego umieścić. I chyba - drogi autorze, było by tak lepiej. Jest to nawiasem mówiąc dokładna kopia posta z forum forbot.

W pierwszej chwili w ogóle myślałem, że to spam, dotyczący tej "nowej" książki, ale wygląda na to, że książka jest z zeszłego roku, więc niezbyt to nowa.

Jeżeli natomiast autor chciałby porozmawiać o tym, co sądzimy o NETMF, to nie ma problemu. Ja zacznę, bo miałem już swoje starcie z tą platformą:

  • pisanie kodu w C# jest super... zwłaszcza dla programistów C#, entuzjastów pragnących tylko wrzucić swoje projekty na mikrokontroler;
  • przenośność kodu pomiędzy embedded a innymi projektami jest super, ale NETMF jest bardzo ograniczone, bardzo - zarówno pod względem obsługiwanych ficzerów języka, jak i pod względem dostępności API pochodzących z innej platformy;
  • a wydajność pozostawia do życzenia;
  • Netduino jest drogie w stosunku do Arduino, praktycznie nie istnieją urządzenia klony. Najtańszy jest STM32F4-DISCOVERY, na który da się skompilować swoją wersję NETMF - aczkolwiek nie udało mi się zrobić tego dla wersji 4.4 tak, żeby to zadziałało. Konkurencyjne platformy oferują o wiele większe możliwości za mniejszą cenę - ESP8266 jest tutaj podstawowym przykładem;
  • Microsoft będzie teraz forsował UWP, które do działania będzie wymagało przynajmniej komputera klasy Raspberry Pi - identyczne API (np. do obsługi GPIO) dla NETMF jest w planie dla wersji 4.5, ale z uwagi na dziwny stan, o którym dalej, niezbyt wiadomo co się stanie;
  • NETMF przez długi czas było w stanie śmierci klinicznej, w zeszłym roku na krótko zmartwychwstało (wydanie 4.4), a teraz jest znów w dziwnym zawieszeniu - i brak komunikacji ze trony opiekunów projektu to jest największy problem.

NETMF nie jest projektem Microsoftu (nawet nie wiem czy jest pod parasolem .NET Foundation), ani projektem w jaki sposób przez nich finansowanym. Wszytko opiera się tylko i wyłącznie na wolontariuszach. GHI zakończyło wsparcie dla ich Gadgeteera, Netduino chyba już nie jest produkowane, OEM-owie się wykruszają jednym słowem. Vide #527.

Bardzo podoba mi się ten projekt, mam do niego olbrzymi sentyment i propagowałem go dość intensywnie - ale bardzo mnie martwi jego potencjalna przyszłość.

0

Moc obliczeniowa tanieje i widzę sporo potencjału w tym rozwiązaniu. Szkoda, że w temacie jest duża stagnacja a projekt nie jest oficjalnie wspierany przez M$, bo przy pomocy C# pisało by się szybko i przyjemnie. Koszty w porównaniu do stosowania C/C++ chyba też byłyby mniejsze?

1
vai0 napisał(a):

Moc obliczeniowa tanieje i widzę sporo potencjału w tym rozwiązaniu. Szkoda, że w temacie jest duża stagnacja a projekt nie jest oficjalnie wspierany przez M$, bo przy pomocy C# pisało by się szybko i przyjemnie. Koszty w porównaniu do stosowania C/C++ chyba też byłyby mniejsze?

Koszty z pewnością były by mniejsze, bo łatwiej znaleźć programistę C# i go przeszkolić do użycia pięciu klas na krzyż niż wziąć programistę embedded C++, poza tym NETMF począwszy od kilku wersji wstecz jest całkowicie darmowy (środowisko+kompilator+interpreter), ale kosztem jest tutaj wydajność - kod IL w NETMF jest interpretowany obecnie, więc znacznie mniej wydajny niż kod natywny. Lekarstwem na to miałby być Lilium, kompilator AoT C#+NETMF dla ARM na bazie LLVM.

1 użytkowników online, w tym zalogowanych: 0, gości: 1