Jak zacząć programować mikrokontrolery w C#? Wymagane narzędzia i programatory

Jestem programistą C#.NET od dosyć dawna. Gdzieś usłyszałem, że istnieje możliwość programowania mikrokontrolerów w C#. Zatem mam pytanie do was, czyli do ludzi którzy mają o tym pojęcie, co jest do tego potrzebne jaki programator i tak dalej. Z góry dzięki za pomoc!!!.

Nestety nie spotkalem się z inplementacją języka c# w kompilatorach dla mikrokontrolerów. Jeśli ktoś dysponuje wystarczającą wiedzą mógłby stworzyć taki projekt. Należałoby zamknąć funkcje w namespace i stworzyć wymagany zbiór bibliotek. Tak naprawdę kompilatory to przede wszyskim parsery kodu, które tłumaczą napisany kod na instrukcje asm (oczywiście w dużxym skrócie). Tak działa "słynny" BASCOM. O jakości kompilatora świadczy "wyprodukowany" przez niego kod wynikowy. Może powstanie jakić projekt Open Source?.

w C# to nie, ale jak znasz C# to chyba ze zwykłym C sobie poradzisz.. a w tym już przecież można programowac uC

Jeżeli chodzi o to co zrobie, to jednak zajmę się twożeniem projektu z C#. Tylko do rzeczy. Mam kod C# przetłumaczyć na ASM tak ?. Dwa potrzebuję jakiegoś taniego i dobrego programatora i oprogramowania do niego.

Pozdrawiam!.

ehh, pytanie, kto bedzie chcial to programowac w C#?
inny problem to taki, ze kompilator C#->asm musialbys robic dla KAZDEGO mikroprocesora (a jest ich multum, nawet tych podstawowych jest sporo i kazdy swoje odmiany ma)
Ewentualne rozwiazanie to zrobic kompilator C#->C, w ten sposob moglbys kazdy mikroprocek zaprogramowac z poziomu C#... ale.. to wszystko sie moim zdaniem mija z celem i pisanie programow w C# pod mikrokontrolery jest chore.


Programator/oprogramowanie... a do jakiego mikrokontrolera? Czesto na programatorach mozesz zaprogramowac tylko pewna rodzine ukladow a nie wszystkie dostepne... z oprogramowaniem jest oczywiscie podobnie.



A jak tak mowa o roznych jezykach, kiedys na forum widzialem genialny post jakiegos newbee. Napisal cos pokroju:
"Skoro assembler jest szybszy od C, to dlaczego ktos nie zrobi, zeby kod z C najpierw byl kompilowany do assemblera a dopiero potem na kod maszynowy?" - no comments

Wcześniej napisałem w dużym skrócie, że kompilator kompiluje do asm, ponieważ asm jest najbardziej zbliżony do jezyka maszynowego. Mówiąc wprost asm jest symbolicznym opisem jezyka maszynowego. Jeżeli chcesz pisać kompilator z prawdziwego zdarzenia musiałby on tłumaczyć instrukcję bezpośrednio do kodu HEX. Nie opłaca się tłumaczyć jezyka do języka (C# -> C). Wydajność i stopień skomplikowania byłby niadekwatny do włożonej pracy. Zauważ, że obecne kompilatory pisane są dla procesorów danego producenta, które mają wspólny zbiór instrukcji (AVR, [PIC, C51 - Intel])różniący się szczegółami związanymi z architekturą poszczególnych układów. Tak naprawdę musiałbyś zaiplementować waszytkie instrukcje oraz bibliotekę architektury procesorów dla danej grupy (np. AVR), poprzez którą ograniczałbyś listę dostępnych instrukcji dla kompilatora ewntualnie parsera i edytora (rozpoznawanie kodu w trakcie pisania). Tali zestaw funkcjonalny (edytor parser kompilator ew. wbudowany programator) to całe środowisko programistyczne. Jak je napiszesz to chętnie wyprubuję.

Pozdrawiam
Mariusz

Ktos tu chyba zapomnial ze kod napisany w jezyku C# (podobnie jak Java) jest wykonywany nie bezposrednio na sprzecie lecz na maszynie wirtualnej.Dla malego mikrokontrolerka jest to zabojstwo w bialy dzien.Po drugie jezyki te sa pozbawione destruktorow co w kontekscie pracy z mikrokontrolerem pozbawilo by go pamieci w bardzo krotkim czasie.No i po trzecie nie widze sensu programowania mikrokontrolerow w jezykach obiektowych.Nie ma to zadnego uzasadnienia praktycznego.Z takim "bagazem" jest w stanie sobie poradzic tylko porzadny procesor z odpowiednimi zasobami.A wiec tylko C panowie i jest to calkowicie wystarczajace narzedzie (w koncu nawet linuksowy kernel jest napisany w C+asm).Pozdrawiam.

Generalnie nie jest taki zły pomysł. Dla tego żeby zrobić coś podobnego trzeba dobrze zrozumieć co to jest platforma .NET. Nawet nie chodzi tu o C#. Platforma .NET jest bardzo zbliżona do JAVA. Czyli, jakim by językiem nie pisać program wychodzi tak zwany assemblecode .NET. Bajer jest taki że po kompilacji jakimkolwiek językiem (C#,J# lub BASIC NET) wychodzi ten sam kod wynikowy. Można korzystać ze standardowych narzędzi na przykład VISUAL STUDIO lub narzędzia open source. A za tym jak podejść do tematu ? Trzeba bardzo dobrze wniknąć w CRL platformy .NET a następnie napisać kompilator (Asemblecode platformy .NET - > kod wynikowy mikrokontrolera). Podobne rozwiązanie jest w przypadku modułów TINI Dallasa http://www.maxim-ic.com/TINIplatform.cfm z tym że tam jest JAVA. Oczywiście nie chodzi tu o wykorzystanie wszystkich namespace w platformie (nie ma takiej możliwości) i oczywiście będą ograniczenia (na przykład jak w przypadku TINI max 16 wątków itd). Ale jako pomysł nie jest zły.

fantom napisał że wykonywanie kodu na CRM (wirtualna maszyna) to zabójstwo dla procesorka!
To nie o to chodzi. Przecież nie będziesz tworzył CRM dla procesorka!
kompilator ma przetworzyć skadnie leksylalną napisanego kodu na 3F 12 0H itp. czyli na kod maszynowy!! W jaki sposób to osiągnąć to jest pytanie tego tego tematu.
1.) Można napisać parser "rozpoznający" składnię C# wraz z kompilatorem przetwarzającym to do kodu maszynowego.
2) Można napisać biblioteki do istniejących środowiska VS .NET które będą kompilowały napisany kod na maszynowy do postaci binarnego HEX

Lepsze jest to drugie rozwiązanie. .NET ma możliwość kompilacji kodu w trakcie wykonania (assembly) Można część kodu potraktować jako "wsad" który będzie przesyłany do kompilatora maszynowego. Ten kod trzeba opakować w standardowy kod sterujący aplikacją. Ten temat nie jest prosty!!!!!. Trzeba wykonać optymalizator. Nie wierżę, że taki projekt może wykonać ktoś, kto nie zna SZCZGÓŁOWO programowania, zasad działania, tipsów i tricków procesorów dla których chce wykonać ten kompilator.
Na koniec dla fantoma: proszę nie mylić języka programowania od jego implementacji!!!!!
C#, C++,C, Java leksykalnie (składniowo) w .NET odpowiadają zasadom (definiowanym w RFC) ale różnią się szczegółami w implementacji. Dlaczego? dlatego że pracują na wspólnych bibliotekach CRM!!!. I nie gra roli czy do metod obiektów odnosimy się przez -> czy . Efekt jest ten sam!!. Proszę za to porównać Borlanda C++ i Pascal (celewo nie piszę Delphi) one również korzystają ze wspólnych bibliotek VCL. Jeśli by podejrzeć źródła MFC,VCL i . NET to one wszystkie opierają się tych samych Windows API!!!.
Twierdzenie że "...Po drugie jezyki te sa pozbawione destruktorow co w kontekscie pracy z mikrokontrolerem pozbawilo by go pamieci w bardzo krotkim czasie.No i po trzecie nie widze sensu programowania mikrokontrolerow w jezykach obiektowych.Nie ma to zadnego uzasadnienia praktycznego..." świadczy o braku praktyki programistycznej. Po co się opakowuje funkcjonalność w obietkty?
Proszę wykonać prosty edytor tekstu poprzez czyste API i zmierzyć czas wykonania. Potem wykonać ten sam projekt w BC++ lub Delphi i .NET (dowolny język). Wykonanie jest jescze proste, ale proszę później dokonać zmiany funkcjonalności edytora na poziomie 30% - 40% zmian kodu i ponownie zmierzyć czas - odpowiedź nasunie się sama. Zamykamy finkcjonalność aby zwiększyć efektywość tworzenia kodu. Destruktory i konstruktory są elementami języka obiektowego. Przecież nie będziemy obiektu zapisywać do mikrokontrolera! natomiast można stworzyć klasę np. UART i zaimplementować w niej funkcjonalność obsługi UART uK. Funkcje wewnątrz UART będą i tak tłumaczone na kod maszynowy!!!

kończę i przepraszam za tak długi wywód
Mariusz

Zdaje sie ze ty z kolei masz bardzo male doswiadczenia w programowaniu mikrokontrolerow.Kod ktory dla nich piszesz musi byc bardzo dobrze zoptymalizowany co w przypadku jezyka obiektowego jest wrecz niemozliwe wlasnie ze wzgledu na jego zbyt duza ogolnosc.Zdefiniowanie interfejsow mozna zrobic poprzez piliki .h a ukrywanie implementacji poprzez odpowiednie biblioteki.Udowodnij mi ze w przypadku nieskopoziomowej obslugi sprzetu sa mi niezbedne takie narzedzia jezyka obiektowego jak polimorfizm i dziedzieczenie kosztem zawalenia moich 512 bajtow pamieci RAM.Z tego co wiem to C++ (ktory jest chyba jedynym w miare rozsadnym jezykiem obiektowym do zastosowania w mikrokontrolerach) doczekal sie juz implementacji na mikrokontrolery MSP430 ale ja w tym wypadku i tak korzystalem tylko z C i chyba na razie jeszcze tak bedzie...Ktos sie moze ze mna oczywiscie niezgodzic ale ja uznaje rozroznienie: mikrokontrolery C - PC-et C++,Java lub co kto tam sobie jeszcze wymysli.

P.S O ile dobrze pamietam glownymi zaletami jezykow takich jak C# i Java mialabyc wieloplatformowosc poprzez ich wirtualne maszyny a nie natywne kompilatory.W tym celu zdecydowanie lepszy jest C++.

Oczywiście że wszystko zależy od optymalizacji!!!
Nie ważne jakie .h implementujesz. Możesz zawsze napisać własne.
Istotą jest zamiana kodu na kod maszynowy!!! Ale nie mów że jest to niemożliwe bo właśnie dlatego napisałem o twoim doświadczeniu. Jeśli ktoś doskonale napisze optymalizator to zmieści kod w 512 bajtów RAM. Nie wiem czy pamietasz ale we wczesnych kompilatorach na PC które miały malutkie w porównaniu do dzisiejszych zasoby sprzętowe musiałeć określać model pamięci dostosowując aplikację do sprzętu na której miała chodzić. Polimorfizm i dziedzicznie określają współdziałanie obiektów czyli metod i funkcji czyli kodu!! Ale ono też ma swoje granice!!! Jakie? nie możesz wyjśc poza zakres podstawych zasad określonych w obiekcie który dziedziczysz!!! Możesz dodać nowe funkcje ale opierając się na obiekcie bazowych czyli je uszczegółowić!!!! Przykład:
Budujemu klasę UART implementujemy w niej zasady komunikacji proca definiujemy klasę jako abstakcyjną czyli konieczną do dziedziczenia.
Ty jako programista nadpisujesz tą klasę i uszegóławiasz informacjami właściwymi dla twojej aplikacji. Potem naciskasz "compile" i kompilator najpierw rozpoznaje składnie (na każdym etapie sprwdza błędy) parsuje optymalizuje i konwertuje ponownie optymalizuje sprawdza i zapisuje do postaci kodu maszynowego. Na razie nie ma C++ czyli obiektówki opisującej programowanie mikrokontrolerów. Ale przy coraz potężniejszych i bardziej skomplikowanych prockach rzeczywistość może wymusić powstanie takiego rozwiązania. Nasza dyskusja przypomia dywagacje na temat DOS czy Windows prowadzone dobrych kilka lat temu - chodzi oczywiście o zady i walety środowisk pod kątem pisania programów, kompilatorów itp. Jak widzisz życie (a raczej czas i Bill Gates) samo rozwiązało ten problem. Jeśli cię uraziłem to przepraszam nie było to moim celem. Sądzę że nikt nie napisał kopilatora składni C++ na uK bo nie było takiej potrzeby. Programy tworzy się z reguły pod potrzeby biznesu. Jeśli coś można zrobić szybciej to znaczy że taniej. Wyjątki to uczelnie (pisanie przez studentów dla wykładowców publikujących swoje nowatorskie prace), dla nauki i sprawdznia swoich możliwości (chcę zrobić coś nowego i mam kupę wolnego czasu i determinacji) oraz zapaleńców (grupa ludzi nie patrząca na pieniądze, nie dysponująca wolnym wolnym czasem ale gotowa poświecić wszytko dla osiągnięcia założonego celu).

Pozdrawiam
Mariusz

PS
Projektowaniem, wdrażaniem systemów informatycznych oraz programowaniem zajmuję się od dłuższego czasu Jestem szefem Zespołu Projektowego w firmie zajmującej się softwarem, dlatego wiem co piszę, a jak nie wiem to nie piszę.

Napisalem przeciez ze jest kompilator C++ (http://mspgcc.sourceforge.net) na mikrokontrolerki MSP430.Wcale nie watpie ze nie masz pojecia i doswiadczenia w programowaniu ale przyznam sie szczerze ze troche krzywo patrze na programistow PC-towych ktorzy takie same maniery chca przeniesc na swiat mikro.Tutaj nie dzialasz pod opieka systemu operacyjnego lecz defakto sam ten system tworzysz.Powiem tak : zrobcie, zobaczymy, przetestujemy i wtedy sie okaze.Jak sie uda to konia z rzedem i moj niski uklon.Pozdrawiam.

Taki dodatek jeszcze ktory mi przyszedl do glowy: zalozmy ze tworysz dwa obiekty danej klasy ktora posiada jakies tam metody.Kazdy z obiektow musi przechowywac wlasne wskazniki do funkcji klasy mimo ze wskazuja dokladnie na to samo.Oszczednosc pamieci ?

Cześć

Zrozum, traktuj PC i oprogramownaie kompilatora jako "tłumacza". PC ma duże zasoby w stosunku do uK. I tam jest miejsce na wskażniki (wskaźnik do fukncji to wskaźnik do jej adresu czyki liczba int -> dokładnie odpowiada miejscu w pamięci gdzie się zaczyna kod fukcji), obiekty itp. Cała sztuka to przetłumaczenie funkcji w postaci kodu napisanego w dowolnej składni do kodu akceptowalengo i wykonywanego przez uK. Wskażnik do funkcji w uK to też adres w pamięci , gdzie się ta funkcja zaczyna. Języki programownia są abstrakcyjnym opisem kodu maszynowego i są stworzone w celu łatwiejszgo programowania. Idąc od dołu kod maszynowy -> asm -> Języki wyższego poziomu (c,c++, pascal, basic, inne). Dodatkowo metody i funkcje enkapsuluje się w funkcjonalne bloki (biblioteki i obiekty). Ale to wszystko i tak musi zostać przetworzone na kod maszynowy. Atlon, Intel i inne to duzi bracia uK i zasady programownia są takie same. Zobacz na asm i architekturę Intela - też masz alu, ,rejestry, stos, pamięć itp. A jak dawniej wyglądały komputerki?
Pamiętasz Spekrtrumnę? Jaki miała procesor? Skąd wywodzi się architektura C51. Właśnie z pierwszych inteli Znając zasady budowy i funkcjonowania procesorów możesz bez większych problemów nauczyć się pisania kodu na kazdy z nich. Praktycy to potwierdzą.
Pierwsze komputery programowało się pisząc jedynie w języku maszynowym. Dla ułatwienia pracy powstały języki opisujące podstawowe instrucje (warunkowe, pętle itp.) funkcje na końcu obiekty wszystko w celu efektywnego pisania programów. Sam najbardziej lubię pisać dla uK w asm bo mam kontrolę nad wszytkim, ale np. dużo osób korzysta z BASCOMA bo go nie interesuje co w danej funkcji siedzi tylko że jest dla niego zrozumiała i prosta w zastosowaniu. Poza tym oszczędza czas.
Na pewno napisanie kompilatora obsługującego składnię C# (obiektową) jest zadaniem dla zapaleńców, chyba że postęp techniczny wymusi potrzebę pojawienia się na rynku takiego produktu.

PS
Z wykształcenia jestem elektronikiem ale odszedłem w stronę informatyki.

Pozdrawiam

MCY ja to wszystko wiem - naprawde .Dlatego wlasnie zauwazam ze bedzie to mniej optymalne rozwiazanie od zwyklego C.Ale spoko jak napisalem wczesniej : jak masz zaciecie to rob a potem zobaczymy co z tego wyjdzie.

P.S. Ja tez .

Ni mam chęci i ochoty do takiej roboty:) Może znajdzie inny szaleniec - zapaleniec.

Pozdrawiam i dziękuję za dyskusję fantom