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

[ackarwow]

Dla osób zainteresowanych: zaktualizowałem ostatnio UnoLib (port Arduino Core Library dla Pascala), dodając obsługę SPI oraz przykład współpracy z wyświetlaczem TFT (ILI9163).

Repozytorium: https://github.com/ackarwow/unolib

[VisualLab]

Mam dwa pytania z sugestiami do Autora programu AVRPascal. Czy:

1. w oknie dialogowym wyświetlającym informacje o programie dałoby się umieścić dodatkowe informacje o:

• wersji kompilatora FPC,
• wersji bibliotek UnoLib,

2. przenieść (lub dodać opcję) określanie częstotliwości zegara MCU z okna dialogowego opcji programu (tj. View -> Options... => Compiler -> Other -> Define clock frequency (F_CPU)) do kodu źródłowego (modułu).

W obecnej wersji AVRPascal'a przy zmianie mikrokontrolera trzeba pamiętać o przejściu do okna dialogowego opcji kompilatora i tam zmienić częstotliwość zegara. Nie jest to złe rozwiązanie, ale czasem zdarza się (np. mnie) zapomnieć o tych ustawieniach. Może najlepszym rozwiązaniem byłby taki wybór, że użytkownik w opcjach ma dwie możliwości:

• definiowanie F_CPU w oknie dialogowym opcji kompilatora (jak dotychczas), wtedy aktywuje się pole pozwalające wpisać wartość częstotliwości,
• definiowanie F_CPU w kodzie źródłowym, za pomocą dyrektywy kompilatora.

 

 

[ackarwow]

3 godziny temu, VisualLab napisał:

Mam dwa pytania z sugestiami do Autora programu AVRPascal. Czy:

1. w oknie dialogowym wyświetlającym informacje o programie dałoby się umieścić dodatkowe informacje o:

• wersji kompilatora FPC,
• wersji bibliotek UnoLib,

2. przenieść (lub dodać opcję) określanie częstotliwości zegara MCU z okna dialogowego opcji programu (tj. View -> Options... => Compiler -> Other -> Define clock frequency (F_CPU)) do kodu źródłowego (modułu).

W obecnej wersji AVRPascal'a przy zmianie mikrokontrolera trzeba pamiętać o przejściu do okna dialogowego opcji kompilatora i tam zmienić częstotliwość zegara. Nie jest to złe rozwiązanie, ale czasem zdarza się (np. mnie) zapomnieć o tych ustawieniach. Może najlepszym rozwiązaniem byłby taki wybór, że użytkownik w opcjach ma dwie możliwości:

• definiowanie F_CPU w oknie dialogowym opcji kompilatora (jak dotychczas), wtedy aktywuje się pole pozwalające wpisać wartość częstotliwości,
• definiowanie F_CPU w kodzie źródłowym, za pomocą dyrektywy kompilatora.

 

 

Dziękuję za ciekawe sugestie. Oto moje przemyślenia:

1) Wersja FPC. To jest możliwe do zrobienia. Obecnie AVRPascal korzysta ze zmodyfikowanej wersji FPC 3.3.1 (poprawka @ccrause w aasmcpu.pas) i od dłuższego czasu nie wprowadzałem już tam zmian. Mogę wyświetlić tę informację w oknie About lub podczas kompilacji w obszarze Messages.

2) Wersja UnoLib. To również jest interesująca propozycja. UnoLib rozwijam równolegle z AVRPascalem, ale obecnie biblioteka nie posiada formalnie zdefiniowanego numeru wersji dostępnego z poziomu IDE. Chyba faktycznie warto dodać mechanizm przechowywania i odczytu wersji, tak aby można ją było wyświetlać w oknie About. Rozważam dodanie odpowiedniego pliku w folderze lib (albo lepiej - wpis w avrpascal.ini), który później byłby interpretowany przez IDE. Taka informacja mogłaby być również udostępniana w postaci symbolu definiowanego dla kompilatora, co byłoby odpowiednikiem:

{$define UNOLIB}
{$define UNOLIB_VERSION:=1}
{$define UNOLIB_RELEASE:=2} //= UnoLib 1.2

wtedy można korzystać w kodzie z konstrukcji

{$if (UNOLIB_VERSION > 1) or ((UNOLIB_VERSION = 1) and (UNOLIB_RELEASE >= 2))}
//jakiś kod
{$endif}

3) Definiowanie F_CPU. Tutaj dobra wiadomość jest taka, że już teraz można definiować częstotliwość zegara bezpośrednio w kodzie źródłowym:

{$define F_CPU:=12000000}

Wartość podana w kodzie ma pierwszeństwo przed wartością ustawioną w opcjach kompilatora. Oznacza to, że można pozostawić domyślną wartość w ustawieniach IDE, a dla konkretnych programów definiować F_CPU bezpośrednio w źródłach. Sprawdziłem taką sytuację w emulatorze i działa ona właśnie w ten sposób. Ale zastanowię się nad tym, czy obecny sposób konfiguracji można jeszcze jakoś ulepszyć.

Edytowano 14 czerwca przez ackarwow

[VisualLab]

Dziękuję za obie odpowiedzi.

1) Zatem rozumiem, że (być może) za jakiś czas pojawią się informacje o wersji kompilatora i biblioteki UnoLib.

2) Myślę, że co do definiowania F_CPU, to obecne możliwości programu AVRPascal są jak najbardziej odpowiednie/zadowalające.

[ackarwow]

17 minut temu, VisualLab napisał:

Dziękuję za obie odpowiedzi.

1) Zatem rozumiem, że (być może) za jakiś czas pojawią się informacje o wersji kompilatora i biblioteki UnoLib.

2) Myślę, że co do definiowania F_CPU, to obecne możliwości programu AVRPascal są jak najbardziej odpowiednie/zadowalające.

Oczywiście, informacje o wersji FPC i UnoLib pojawią się w oknie About w kolejnej wersji AVRPascal IDE. Okno będzie wyglądało mniej więcej tak (to bieżąca wersja testowa).

Jedyna różnica względem moich początkowych założeń jest taka, że informacje te nie będą przechowywane w pliku INI, lecz zostaną zapisane bezpośrednio w zasobach pliku EXE razem z pozostałymi informacjami o wersji programu.

Dziękuję jeszcze raz za sugestie.

[VisualLab]

22 godziny temu, ackarwow napisał:

Jedyna różnica względem moich początkowych założeń jest taka, że informacje te nie będą przechowywane w pliku INI, lecz zostaną zapisane bezpośrednio w zasobach pliku EXE razem z pozostałymi informacjami o wersji programu.

A co w sytuacji, gdy użytkownik manualnie zaktualizuje kompilator FPC (mało prawdopodobne, ale możliwe) lub bibliotekę UnoLib (bardziej prawdopodobne)?

[ackarwow]

1 godzinę temu, VisualLab napisał:

A co w sytuacji, gdy użytkownik manualnie zaktualizuje kompilator FPC (mało prawdopodobne, ale możliwe) lub bibliotekę UnoLib (bardziej prawdopodobne)?

Dobre pytanie, zastanawiałem się nad tym.

Chyba muszę przyjąć założenie (zgodne zresztą z opisem na stronie WWW), że są to wersje FPC i UnoLib, z jakimi dystrybuowane jest AVRPascal IDE.
Oczywiście użytkownik może później podmienić kompilator FPC lub pliki UnoLib, ale są to już jego własne modyfikacje środowiska. W takim przypadku informacje wyświetlane w oknie About przestaną opisywać rzeczywisty stan instalacji i zaczną określać jedynie oryginalny zestaw dystrybucji IDE.

Alternatywą byłoby automatyczne wykrywanie wersji FPC i UnoLib podczas działania programu. W przypadku FPC można teoretycznie odczytać wersję z linii komend, a w przypadku UnoLib zastosować dodatkowy plik z informacją o wersji lub odpowiednie definicje w źródłach. Takie rozwiązanie byłoby jednak bardziej złożone i nie dawałoby gwarancji poprawnego wyniku (np. własne kompilacje FPC/częściowo podmienione pliki biblioteki).

Dlatego na obecnym etapie skłaniam się ku najprostszemu rozwiązaniu i traktowaniu tych informacji jako wersji dystrybucji. Ale oczywiście chętnie poznam Pana opinię na ten temat.

[H1M4W4R1]

5 godzin temu, ackarwow napisał:

Takie rozwiązanie byłoby jednak bardziej złożone i nie dawałoby gwarancji poprawnego wyniku (np. własne kompilacje FPC/częściowo podmienione pliki biblioteki).

Weryfikacja plików po SHA1, która zajmuje mniej niż sekundę dla dość sporej ilości + wyświetlanie "Unknown" dla nieznanych dystrybucji albo XXX (modified) dla znanych, ale z błędami walidacji?

[ackarwow]

11 minut temu, H1M4W4R1 napisał:

Weryfikacja plików po SHA1, która zajmuje mniej niż sekundę dla dość sporej ilości + wyświetlanie "Unknown" dla nieznanych dystrybucji albo XXX (modified) dla znanych, ale z błędami walidacji?

Tak, to byłoby możliwe do zrobienia, ale mam wrażenie, że prowadziłoby już w stronę mechanizmu kontroli integralności IDE, a nie prezentacji informacji o wersji.

Sądzę, że okno About powinno przede wszystkim informować, z jakimi wersjami FPC i UnoLib została przygotowana dana dystrybucja IDE. Jeżeli użytkownik zaczyna ręcznie podmieniać kompilator lub biblioteki, to w praktyce tworzy już własny wariant środowiska. Oczywiście można próbować wykrywać takie modyfikacje (SHA1, sumy kontrolne, porównywanie plików itd.), ale wtedy pojawia się pytanie, czy IDE powinno to robić. Bo w efekcie powstanie pewnego rodzaju wyścig między swobodą modyfikacji środowiska przez użytkownika a próbą wykrywania tych zmian przez IDE. Więcej, nawet można założyć, że część użytkowników będzie modyfikować moduły UnoLib z oryginalnej dystrybucji (i nie ma w tym nic złego) pobierając zmiany robocze jakie publikuję od czasu do czasu na GitHubie (albo tworząc własne ulepszenia). Jaką wartość dla użytkownika będzie miał opis "FPC/UnoLib version: unknown" jeśli załóżmy wszystko się kompiluje i działa?

[H1M4W4R1]

9 minut temu, ackarwow napisał:

Jaką wartość dla użytkownika będzie miał opis "FPC/UnoLib version: unknown" jeśli załóżmy wszystko się kompiluje i działa?

Taką, że ta wersja nie jest oficjalnie wspierana i może zawierać błędy. I to nie idzie w stronę kontroli integralności IDE, ale w stronę informowania użytkownika, że IDE nie wie co to jest i warto przygotować jakiś plik informacyjny z wersją biblioteki. Tutaj dobre rozwiązanie ma PlatformIO, które używa plików JSON ze wszystkimi metadanymi.

Z doświadczenia wiem, że zdecydowanie warto rozdzielać wersje "oficjalne" od "nieoficjalnych". Większość użytkowników potrafi sprawiać przy tym duże problemy, nawet jeżeli uważamy, że są oni zaawansowani technicznie (jak w przypadku tego projektu).

[ackarwow]

Przed chwilą, H1M4W4R1 napisał:

Taką, że ta wersja nie jest oficjalnie wspierana i może zawierać błędy. I to nie idzie w stronę kontroli integralności IDE, ale w stronę informowania użytkownika, że IDE nie wie co to jest i warto przygotować jakiś plik informacyjny z wersją biblioteki. Tutaj dobre rozwiązanie ma PlatformIO, które używa plików JSON ze wszystkimi metadanymi.

Z doświadczenia wiem, że zdecydowanie warto rozdzielać wersje "oficjalne" od "nieoficjalnych". Większość użytkowników potrafi sprawiać przy tym duże problemy, nawet jeżeli uważamy, że są oni zaawansowani technicznie (jak w przypadku tego projektu).

Tak, to jest argument. Użytkownik może zgłosić błąd, po czym okazuje się, że wynika on z jego własnych modyfikacji środowiska. Z drugiej strony wersja oficjalna również może zawierać błędy ("nobody is perfect"), zwłaszcza jeśli program jest aktywnie rozwijany. To też jest całkowicie normalne.

Nadal nie jestem przekonany, czy IDE powinno próbować wykrywać takie zmiany. Raczej skłaniam się ku temu, aby okno About informowało o wersjach komponentów dostarczonych wraz z dystrybucją. Być może wystarczyłoby dodać tam określenie "distributed version" zamiast samego "version". To byłaby jasna wskazówka, że chodzi o wersje dostarczone wraz z IDE, a nie o aktualny stan wszystkich plików w katalogu instalacji.

Edytowano 16 czerwca przez ackarwow

[VisualLab]

To jest spory dylemat, bo lepsze zawsze jest wrogiem dobrego. Może na razie wystarczy informować użytkownika o wersjach kompilatora i biblioteki dostarczanych razem z IDE.

[ackarwow]

Opublikowałem nową wersję AVRPascal IDE (3.8). Zmiany:

Nowa wersja UnoLib (1.3, szczegóły na stronie https://sourceforge.net/projects/unolib/)
Nowe funkcje i usprawnienia:
- dodano funkcję Tools -> Check Device (informacja o aktualnie podłączonym mikrokontrolerze odczytana przez AVRDude)
- dodano obsługę programowania TPI przez USBasp (wybrane mikrokontrolery z rodziny ATtiny; podziękowania dla @sp3ots za sugestie)
- dodano obsługę programowania ISP przez Arduino (interfejs ArduinoISP; podziękowania dla Christofa Binera za sugestię)
- dodano informacje o wersjach FPC i UnoLib w oknie "About"; informacje o wersji UnoLib są również dostępne w postaci symboli kompilatora (UNOLIB, UNOLIB_VERSION, UNOLIB_RELEASE, UNOLIB_FULLVERSION). Podziękowania dla @VisualLab za sugestię.
- usprawniono menu kontekstowe Monitora portu szeregowego oraz dodano obsługę szybkości transmisji 19200 bodów
- dodano definicje wyprowadzeń mikrokontrolerów (57 układów ATmega, 22 układy ATtiny, 6 płytek Arduino)
Poprawki błędów:
- poprawiono obsługę plików INC podczas edycji kodu (problemy z ELinkScannerError)



Program tradycyjnie można pobrać tutaj:
https://akarwowski.pl/index.php?page=elektronika&lang=pl
https://avrpascal.pl

PS. @H1M4W4R1, @VisualLab
Na razie zastosowałem najprostszy sposób informowania o wersjach FPC i UnoLib w oknie "About" zaszywając je statycznie w programie (mój błąd - zapomniałem dopisać "distributed", poprawię w kolejnej wersji). Ale pomysł z wykrywaniem zmian jest ciekawy, myślę że z czasem go wprowadzę. Dziękuję Wam za świetne pomysły i dyskusję.