Darmowy edytor kodu w języku Pascal dla mikrokontrolerów AVR

[ackarwow]

Kłaniam się wszystkim Forumowiczom

Chciałbym zaproponować Wam edytor mojego autorstwa przeznaczony do pisania programów w Pascalu dla mikrokontrolerów AVR, który nazwałem AVRPascal. AVRPascal wykorzystuje kompilator Free Pascal do tworzenia pliku wynikowego oraz AVRdude, który umożliwia zapisanie kodu w pamięci mikrokontrolera z użyciem programatora USBasp lub płytki Arduino (AVRPascal obsługuje kilka typów płytek).

AVRPascal posiada:
- podświetlaną składnię, w przypadku błędów kompilacji wskazuje linię kodu, w której wystąpił błąd
- podpowiedzi parametrów funkcji i procedur oraz pól typów rekordowych i metod typów klasowych
- możliwość pracy z wieloma plikami w zakładkach
- możliwość konfiguracji fuse-bitów mikrokontrolera
- możliwość automatycznego wykrycia obsługiwanych urządzeń USB (tj USBAsp, płytek Arduino)

AVRPascal jest absolutnie darmowy (freeware). Program staram się rozwijać na bieżąco, nowe wersje pod Windows, Linux i MacOS umieszczam na mojej stronie internetowej.

Jeśli korzystacie z Arduino Uno to może Wam się przydać biblioteka UnoLib, którą dołączyłem do edytora. Jest to tłumaczenie na język Pascal części standardowej biblioteki Arduino oraz dodatkowo kilka przykładowych projektów. Oczywiście biblioteka nadaje się do programowania ATMega328p bez Arduino.

Jeśli nie mieliście do tej pory styczności z językiem Pascal to na mojej stronie znajdziecie również kurs programowania AVR-ów z użyciem AVRPascala. Jest to darmowy kurs w formie PDF-ów opisujący od podstaw jak pisać proste programy w języku Pascal tym razem dla ATTiny13.

Mam nadzieję, że program się Wam spodoba. Będę wdzięczny za wszelkie komentarze (szczególnie te krytyczne).

[FlyingDutch]

Cześć,

naprawdę fajny projekt - gratuluje. Pascal to pierwszy język wysokiego poziomu, jakiego się nauczyłem -mam do niego duży sentyment.

Pozdrawiam

[ackarwow]

2 godziny temu, FlyingDutch napisał:

Cześć,

naprawdę fajny projekt - gratuluje. Pascal to pierwszy język wysokiego poziomu, jakiego się nauczyłem -mam do niego duży sentyment.

Pozdrawiam

Dzięki za miłe słowa Proponuję więc wypróbować program, nie trzeba niczego dodatkowego instalować -  kompilator FPC, linker i AVRdude instalują się razem z programem. Są też przykładowe projekty dla Arduino Uno (w paczce instalacyjnej) oraz ATTiny13 (PDF-y na stronie). Ponadto użytkownicy mają wpływ na kształt programu - dodałem ostatnio formater kodu na prośbę jednego z użytkowników.

Pozdrawiam serdecznie   

[FlyingDutch]

3 godziny temu, ackarwow napisał:

Dzięki za miłe słowa Proponuję więc wypróbować program, nie trzeba niczego dodatkowego instalować -  kompilator FPC, linker i AVRdude instalują się razem z programem. Są też przykładowe projekty dla Arduino Uno (w paczce instalacyjnej) oraz ATTiny13 (PDF-y na stronie). Ponadto użytkownicy mają wpływ na kształt programu - dodałem ostatnio formater kodu na prośbę jednego z użytkowników.

Pozdrawiam serdecznie   

Mam zamiar wypróbować ten edytor.

Pozdrawiam

[H1M4W4R1]

W sumie fajny projekt, chociaż wolę języki, które gwarantują type-safety (przykładowo C#, w którym ciężko coś zepsuć), ale to by już wymagało pisania kompilatora od zera (dość proste zadanie, ale ciężko zagwarantować jego poprawne działanie dla wszystkiego co użytkownik tam wstawi).

[ackarwow]

22 minuty temu, H1M4W4R1 napisał:

W sumie fajny projekt, chociaż wolę języki, które gwarantują type-safety (przykładowo C#, w którym ciężko coś zepsuć), ale to by już wymagało pisania kompilatora od zera (dość proste zadanie, ale ciężko zagwarantować jego poprawne działanie dla wszystkiego co użytkownik tam wstawi).

Dzięki za komentarz. Zakładam, że użytkownik/programista wie co robi, a przynajmniej wie co chce zrobić - więc jak będzie chciał co zepsuć to i tak zepsuje

Nie zauważyłem aby Pascal pozwalał na jakąś szczególną dowolność w konwersji typów danych, wydaje mi się, że jest wystarczająco szczelny w tym zakresie. Ale to moje wrażenie, moge się mylić. Z drugiej strony często mam potrzebę rzutowania typu (type-casting) w kodzie dla AVR-ów więc dla minie ta cecha języka (tj. type-safety) nie jest najistotniejsza. Chociaż rozumiem, że w wielu przypadkach się przydaje aby uniknąć błędów.

Myślę, że przypadku Pascala dla AVR-ów (czywiście także C i pewnie wielu inych języków) większym atutem jest możliwość wstawek asemblerowych. Chociaż optymalizacja w kompilatorze FPC dla AVR działa nieźle, czasem warto mieć pełną kontrolę nad tym co trafia do pamięci flash mikrokontrolera

[FlyingDutch]

Dnia 4.01.2025 o 16:31, H1M4W4R1 napisał:

W sumie fajny projekt, chociaż wolę języki, które gwarantują type-safety (przykładowo C#, w którym ciężko coś zepsuć), ale to by już wymagało pisania kompilatora od zera (dość proste zadanie, ale ciężko zagwarantować jego poprawne działanie dla wszystkiego co użytkownik tam wstawi).

Cześć,

Pascal jest językiem "strong typed" i gwarantuje type-safety tak samo jak C/C++, czy C#

Pozdrawiam

[H1M4W4R1]

45 minut temu, FlyingDutch napisał:

Pascal jest językiem "strong typed" i gwarantuje type-safety tak samo jak C/C++, czy C#

Bardziej chodziło o wymagania typu: wymuszenie bezpośredniej deklaracji, że dany obiekt może być null'em (lub nie) czy tego że dana struktura może istnieć tylko na stosie. Ewentualnie, że w danym segmencie kodu nie jest dozwolone przekroczenie zakresu liczbowego (ew. dozwolone).

Nie znam na tyle Pascala, by od ręki stwierdzić, że to na 100% tam nie istnieje, ale w C zdecydowanie tego nie widziałem.

[ackarwow]

3 godziny temu, H1M4W4R1 napisał:

Bardziej chodziło o wymagania typu: wymuszenie bezpośredniej deklaracji, że dany obiekt może być null'em (lub nie) czy tego że dana struktura może istnieć tylko na stosie. Ewentualnie, że w danym segmencie kodu nie jest dozwolone przekroczenie zakresu liczbowego (ew. dozwolone).

Nie znam na tyle Pascala, by od ręki stwierdzić, że to na 100% tam nie istnieje, ale w C zdecydowanie tego nie widziałem.

Myślę, że większym bólem głowy, szczególnie w przypadku złożonych projektów jest rozmiar kodu, a raczej jego ograniczenia wynikające z rozmiaru dostępnej w mikrokontrolerze pamięci flash. Chodzi więc o to, żeby kod wynikowy zmieścił się w pamięci, dlatego wcześniej pisałem o wstawkach asemblerowych. To oczywiście tylko jedna z potencjalnych metod redukcji rozmiaru kodu wynikowego...

[VisualLab]

Trochę przeterminowany wątek, ale czego się nie robi dla potomności :)

Dnia 10.01.2025 o 11:00, H1M4W4R1 napisał:

Bardziej chodziło o wymagania typu: wymuszenie bezpośredniej deklaracji, że dany obiekt może być null'em (lub nie) czy tego że dana struktura może istnieć tylko na stosie. Ewentualnie, że w danym segmencie kodu nie jest dozwolone przekroczenie zakresu liczbowego (ew. dozwolone).

Nie znam na tyle Pascala, by od ręki stwierdzić, że to na 100% tam nie istnieje, ale w C zdecydowanie tego nie widziałem.

Do dużych struktur (w tym klas) to jest rzeczywiście przydatne, jeśli można zadeklarować typ, który nie może przyjmować wartości null z jakiegoś słusznego powodu. Obecne kompilatory Pascal'a i Object Pascal'a (tj. DCC, FPC) tego nie obsługują.

W kompilatorze Pascal'a dla mikrokontrolerów to nawet nie powinno się pojawić (za duży narzut pamięciowy). Natomiast w Object Pascal'u mogłoby to być czasem przydatne. Na forum FPC pojawiały się deklaracje, że być może w przyszłych wersjach będzie taka możliwość. Zobaczymy. W każdym razie to nie jest cecha języka programowania, bez której nie da się żyć (ale byłoby miło to mieć).

Niestety w niektórych językach wymieniona cecha obejmuje typy proste. No i to już jest niesamowicie kretyński pomysł. Bo dajmy na to, że jakaś funkcja biblioteczna zwykle zwraca liczbę całkowitą, ale czasem może zwrócić null. Pomysł rodem ze starszych wersji PHP (tj. przed 8.0). Ale w C# to niestety jest! Dokumentacja MS o tym wyraźnie wspomina (https://learn.microsoft.com/pl-pl/dotnet/csharp/language-reference/builtin-types/nullable-value-types).

Podsumowując: null jako brak danych dla typów referencyjnych jest OK, ale dla typów wartości (boolowskie, liczby całkowite, liczby zmiennoprzecinkowe, wyliczenia, itp.) nie powinno to być obsługiwane, bo wprowadza bałagan. Tłumaczenie, że to jest potrzebne do obsługi baz danych (bo z takim "wyjaśnieniem" się spotkałem) jest głupie i ma swoje źródło w lenistwie niektórych programistów.

[H1M4W4R1]

39 minut temu, VisualLab napisał:

Podsumowując: null jako brak danych dla typów referencyjnych jest OK, ale dla typów wartości (boolowskie, liczby całkowite, liczby zmiennoprzecinkowe, wyliczenia, itp.) nie powinno to być obsługiwane, bo wprowadza bałagan.

W C# istnieje to z innego powodu: dla struktur danych. To one są problematyczne w niektórych momentach i w ten sposób unikasz konieczności dodawania flagi "isValid" w miliardzie struktur... fakt, dużo ciężej wyrównać to w pamięci by uniknąć rozproszonej alokacji, ale się da  

A często chcesz wymusić by coś było przekazywane tylko na stosie (pozdrawiamy współpracowników), a wtedy klasy kompletnie odpadają, bo gwarantują alokację sterty, a wskaźniki nie są zbyt bezpiecznym rozwiązaniem.

I zwrócenie null jest praktyczne kiedy wartość jest całkowicie błędna - zamiast wykorzystywać -1, int.Infinity czy MyEnum.INVALID możesz po prostu dać tam null i od ręki wiesz, że coś poszło nie tak.

43 minuty temu, VisualLab napisał:

Do dużych struktur (w tym klas)

W C# struktura i klasa to zupełnie odmienne rodzaje obiektów o gigantycznej różnicy w zachowaniu pod względem przekazywania danych do/z funkcji - struktura jest zazwyczaj alokowana na stosie (da się to zrobić na stercie, ale jako element innego obiektu), a klasa zawsze jest alokowana na stercie. W dodatku struktury dzielą się na zarządzane i niezarządzane, gdzie te drugie pozwalają na gigantyczne optymalizacje wydajności kodu (mój obecny rekord to 210 razy większa wydajność po przeróbkach).

O pracy z referencjami do struktur oraz rodzajami referencji można napisać kolejny referat  

Podsumowanie

IMO nullable dla typów prostych jest przydatne by obsłużyć wyjątki bez żadnych kombinacji. Jest to zwykła struktura z bool'em i wartością, która praktycznie nie wpływa na wydajność kodu - mając możliwość dodatkowego narzędzia bez żadnych komplikacji czemu by z tego nie skorzystać?

Btw. "nullable" dla typów referencjnych są rozwiązywane w czasie kompilacji i nie trafiają do kodu wynikowego - to tylko info dla kompilatora by ładnie wykrywał błędy.

Oraz dodatkowa ciekawostka: IL2CPP stworzony przez Unity Technologies na rzecz Unity3D w momencie konwersji kodu IL (skompilowany C#) na C++ używa wskaźników zarówno w przypadku typów referencyjnych jak i wartościowych, które są oznaczone jako nullable, więc w tym przypadku masz zerowy narzut pamięciowy i nie musisz pisać "unsafe" kodu (albo uprawiać czarnej magii z referencjami)  

[ackarwow]

Dziękuję za ciekawą dyskusję Dodam od siebie, że programiście piszącemu na codzień w C może przeszkadzać brak obsługi złożonych funkcji preprocesora przez FPC. Obsługiwane są jedynie proste przypisania i definicje i (o ile mi wiadomo) twórcy kompilatora nie mają w planach zmian w tym zakresie. Mi osobiście to nie przeszkadza, ale podczas prac nad UnoLib (tłumaczenie biblioteki Arduino dla Arduino Uno na Pascal) funkcje preprocesora musiałem tłumaczyć na regularny kod, posiłkując się inliningiem (gdzie to możliwe) w celu zmniejszenia rozmiaru kodu wynikowego.

Przy okazji: jeśli ktoś miałby ochotę do współpracy (pro bono) w tłumaczeniu/dodawaniu nowch funkcji do UnoLib to zapraszam. O postępie w pracach informujemy na forum FPC ("UnoLib - library in Pascal for Arduino Uno and ATMega328p").

PS. Dostępna jest nowa wersja AVRPascala 3.1 na http://akarwowski.pl/index.php?page=elektronika&lang=pl

[VisualLab]

15 godzin temu, H1M4W4R1 napisał:

I zwrócenie null jest praktyczne kiedy wartość jest całkowicie błędna - zamiast wykorzystywać -1, int.Infinity czy MyEnum.INVALID możesz po prostu dać tam null i od ręki wiesz, że coś poszło nie tak.

Tylko że to zależy często od tego, co taka wartość reprezentuje. Jeśli zmienna to liczba rzeczywista, to z matematycznego punktu widzenia, każda jej wartość jest prawidłowa (tj. w zakresie od -INF do +INF). Podobnie jest z liczbą całkowitą. Jednak, jeśli taka liczba reprezentuje jakiś parametr fizyczny (czy chemiczny), to już zmienia postać rzeczy, bo one często mają zakres, np. pH od 0 do 15, liczba atomowa od 1 wzwyż (i tylko całkowite wartości), stężenie czy masa atomowa nie mogą być ujemne. To są oczywiście trywialne przykłady. Zwykle sytuacja bywa o wiele bardziej skomplikowana. Zatem takie zmienne i tak trzeba sprawdzać.

15 godzin temu, H1M4W4R1 napisał:

W C# struktura i klasa to zupełnie odmienne rodzaje obiektów o gigantycznej różnicy w zachowaniu pod względem przekazywania danych do/z funkcji - struktura jest zazwyczaj alokowana na stosie (da się to zrobić na stercie, ale jako element innego obiektu), a klasa zawsze jest alokowana na stercie.

Tak, masz rację. Ale ja tu nie miałem na myśli struktur w znaczeniu języka C ("struct") i języków pochodnych, tylko ogólnym. Jako rodzaj czegoś złożonego z mniejszych elementów (składowych), bez odnoszenia się do tego, jak one są zrealizowane w konkretnym języku.

15 godzin temu, H1M4W4R1 napisał:

W dodatku struktury dzielą się na zarządzane i niezarządzane, gdzie te drugie pozwalają na gigantyczne optymalizacje wydajności kodu (mój obecny rekord to 210 razy większa wydajność po przeróbkach).

Bo w C# wiele szczegółów języka jest rozwiązanych (wdrożonych) nie w kompilatorze ale w maszynie wirtualnej (jak to jest w przypadku struktur w C# to nie wiem, czy to kompilator za to odpowiada, czy VM). W językach takich jak Object Pascal to musi być rozwiązane w kompilatorze, bo on generuje kod maszynowy. Kompilatory DCC i FPC obsługują rekordy zwykłe i zarządzane. Ale działanie tego w kompilatorze jest z pewnością inne niż w C#.

4 godziny temu, ackarwow napisał:

Dodam od siebie, że programiście piszącemu na codzień w C może przeszkadzać brak obsługi złożonych funkcji preprocesora przez FPC. Obsługiwane są jedynie proste przypisania i definicje i (o ile mi wiadomo) twórcy kompilatora nie mają w planach zmian w tym zakresie. Mi osobiście to nie przeszkadza, ale podczas prac nad UnoLib (tłumaczenie biblioteki Arduino dla Arduino Uno na Pascal) funkcje preprocesora musiałem tłumaczyć na regularny kod, posiłkując się inliningiem (gdzie to możliwe) w celu zmniejszenia rozmiaru kodu wynikowego.

Powód tego, że preprocesor nie jest dostępny w Pascal'u (FPC, DCC) jest od dawna znany. O ile pamiętam, zarówno Wirth jak i wielu innych tuzów świata IT mocno krytykowało preprocesor (także ten w C) jako prymitywną metodę uogólniania kodu. Chyba nawet Stroustrup go krytykował (wszak był propagatorem szablonów w C++). I to jest racja. Preprocesor jest niezwykle prymitywnym rozwiązaniem i stwarza więcej problemów niż oferuje korzyści. Stosowany głównie z powodu lenistwa programistów. I jest to bardzo naiwny sposób uogólniania kodu źródłowego. No ale we wczesnych latach IT był dość wygodną protezą. Wtedy kody źródłowe (OS'ów, programów) były o wiele prostsze (bo i komputery były proste w budowie). Tylko że to się dość szybko zestarzało (a komputerom skomplikowała budowa). W zasadzie preprocesor nie powinien być już od dawna stosowany (przynajmniej do 2000 roku). Ale póki C ma znaczący udział, póty preprocesor będzie używany. Za dużo kodu powstało (głównie biblioteki i OS'y), więc nikt tego nie będzie poprawiał. A zrzucenie tego zadania na (modną obecnie) AI to za duże ryzyko, że w takim kodzie pojawią się błędy.

[ackarwow]

Nowa wersja AVRPascala (3.2) jest dostępna tutaj

Nowe funkcje: 

- zmieniono ikonę "New", dodano przycisk "Upload" na pasku narzędzi (podziękowania dla @Dzandaa za sugestie) 

- dodano okno dialogowe "New file" z możliwością wyboru szablonu nowego dokumentu 

- dodano monitor portu szeregowego (Serial Port Monitor) inspirowany "RS232 Terminal" autorstwa @Dzandaa oraz monitorem portu szeregowego z Arduino IDE; dostępny w menu View->Serial Port Monitor, parametry konfiguracji w oknie "Options", zakładka "Other"

Poprawki błędów: 

- MacOS: poprawiono działanie mechanizmów korzystających z wątków 

- drobne poprawki w oknie "About"

- usunięto nieznaczne wycieki pamięci

[ackarwow]

Przygotowałem kolejną część kursu programowania AVR-ów z użyciem AVRPascala. Nowy "odcinek" dotyczy obsługi wyświetlaczy 7-segmentowych z użyciem ATtiny13 i dodatkowych układów scalonych. Osoby zainteresowane zapraszam do lektury .

 

KursAVR_04.pdf KursAVR_04_Kod.zip

Edytowano Czerwiec 8, 2025 przez ackarwow
Ponowne przesłanie załączników