Licznik do owijarki bel

[ethanak]

7 godzin temu, VisualLab napisał:

Czym różnią się typy: "uint" i "uint32_t"?

Tym, że uint to inaczej "unsigned int" i ma wielkość zależną od kompilatora i ustawień (z reguły to 16 albo 32 bity). uint32_t to alias do odpowiedniego typu który akurat jest 32-bitowy (z reguły unsigned int albo unsigned long)

7 godzin temu, VisualLab napisał:

Wydaje mi się, że zarówno "uint" jak i "uint32_t" jest aliasem do "unsigned int"

Owszem masz rację. Wydaje Ci się 🙂

7 godzin temu, VisualLab napisał:

jest 4-ro bajtowy (może w jakichś starych kompilatorach C było inaczej

Np. starym kompilatorem jest avr-gcc z zeszłego tygodnia?

7 godzin temu, VisualLab napisał:

Mam niewielką styczność z mikrokontrolerami

Rozumiem że stąd te pytania. Na wszelki wypadek zerknij na tabelkę zamieszczoną na tej stronie - powinna dokładniej wyjaśnić niektóre zawiłości C++.

[VisualLab]

Okazało się, że jedno z moich pytań sprawiło pewien kłopot „niektórym” czytającym (bynajmniej nie jest to Autor projektu 🙂). Jeden z uczestników forum przesłał mi objaśnienie. Niestety, nie do końca na temat (co jest oczywiste, bo na to pytanie tylko Autor projektu jest w stanie odpowiedzieć).

10 godzin temu, ethanak napisał:

Tym, że uint to inaczej "unsigned int" i ma wielkość zależną od kompilatora i ustawień (z reguły to 16 albo 32 bity). uint32_t to alias do odpowiedniego typu który akurat jest 32-bitowy (z reguły unsigned int albo unsigned long)

Owszem masz rację. Wydaje Ci się 🙂

Np. starym kompilatorem jest avr-gcc z zeszłego tygodnia?

Rozumiem że stąd te pytania. Na wszelki wypadek zerknij na tabelkę zamieszczoną na tej stronie - powinna dokładniej wyjaśnić niektóre zawiłości C++.

Te różnice w typach są mi znane (chociażby z podręczników czy kodu bibliotek). Dlatego zadałem to pytanie Autorowi projektu. Otóż moje całe pytanie (wraz ze szczegółami doprecyzowującymi) było następujące:

18 godzin temu, VisualLab napisał:

2. Czym różnią się typy: "uint" i "uint32_t"? Występują na przykład w funkcji "gpio_callback(uint gpio, uint32_t events)". Pytam dlatego, bo w kodzie SDK⁽¹⁾ dla RPi Pico w niektórych funkcjach występują takie deklaracje argumentów (tj. w nagłówku funkcji pojawia się obok siebie te dwa typy). Wydaje mi się, że zarówno "uint" jak i "uint32_t" jest aliasem do "unsigned int" i jest 4-ro bajtowy (może w jakichś starych kompilatorach C było inaczej). Ujednolicenie typów dałoby spójniejszy kod.

Żeby nie było niejasności i niedomówień, doprecyzuję o co w tym pytaniu chodziło: „Czym różnią się typy "uint" i "uint32_t" użyte w kodzie projektu?”

W pierwotnym pytaniu jest wyraźnie podane, że mam na myśli funkcję „gpio_callback”, napisaną przez Autora projektu. W dalszej części tego pytania jest doprecyzowane, że mam na myśli:

1. fragment kodu użyty w projekcie licznika owijarki (i żaden inny),
2. użyty w projekcie mikrokontroler RPi Pico, oparty na rdzeniu ARM 32-bity (i żaden inny),
3. SDK RPi Pico jako przykład (tylko i wyłącznie z powodu w/w mikrokontrolera),
4. typy które są mi znane jako aliasy z: dokumentacji, poradników, książek i kodu źródłowego bibliotek języka C.

Zatem zbierając to razem: rzecz dotyczy kodu napisanego na potrzeby projektu dla kompilatora języka C, który jest zdolny generować kod maszynowy dla procesora ARM 32-bit. Nie interesują mnie inne mikroprocesory i mikrokontrolery, bo nie były używane w projekcie (czyli np. AVR). Nie chodziło mi absolutnie o żadne ogólne dywagacje na temat typów w języku C. Miałem na myśli tylko i wyłącznie krótką odpowiedź co do szczegółu projektu. Autor ze znanego sobie powodu tak to zakodował i już. Mnie tylko ciekawiło, dlaczego tak to zrobił. Być może dowiedziałbym się o jakimś nieszablonowym lub interesującym podejściu.

Co do mojego zastrzeżenia dotyczącego mikrokontrolerów PIC:

18 godzin temu, VisualLab napisał:

P.S. Pytania są z czystej ciekawości. Mam niewielką styczność z mikrokontrolerami, poza prostymi projektami z użyciem 8-bitowców z rodziny PIC. Programuję dla zwykłych komputerów.

Przecież w ich przypadku też używa się języka C (oczywiście można użyć asemblera, czy innych języków). Więc z tą znajomością C nie jest u mnie aż tak źle. Pytanie wynikało raczej z tego, że między kompilatorami i bibliotekami dla konkretnego mikroprocesora lub mikrokontrolera będą/mogą występować pewne różnice. Mnie wydaje się oczywiste, że kiedy zabieram się za jakiś projekt, to najpierw zapoznaję się (przynajmniej pobieżnie) z narzędziami: tj. edytorem/IDE, kompilatorem i bibliotekami (jeśli nie miałem z nimi styczności). Każdy kto ma wiedzę, kiedyś jej nie miał, więc ją nabywał/uzupełniał. To oczywiste. Teraz na przykład uzupełniam wiedzę na temat mikrokontrolerów ARM 32-bit. Ale jak napisałem wyżej – w tym pytaniu nie interesowały mnie żadne ogólne dywagacje. Gdyby tak było, założyłbym osobny temat.

I na koniec sprostowanie, co do strony WWW, polecanej przez mojego Szanownego Przedmówcę:

10 godzin temu, ethanak napisał:

Na wszelki wypadek zerknij na tabelkę zamieszczoną na tej stronie - powinna dokładniej wyjaśnić niektóre zawiłości C++.

Podana strona dotyczy języka C++. Trzeba być ostrożnym, ponieważ nie ma 100% zgodności pomiędzy językami C i C++ (kompilatory, biblioteki). Raczej należałoby w tym przypadku (tj. ARM 32-bit) sprawdzić różnice pomiędzy kompilatorami: GCC ( np.: https://www.gnu.org/software/libc/manual/html_node/Integers.html), ARM.

Powyższe wyjaśnienie było potrzebne „dla potomności”. W przeciwnym wypadku inni uczestnicy forum mogliby odnieść błędne wrażenie, że o coś pytam a nawet nie wiem za bardzo o co. Wszelkie niejasności należy bowiem prostować.

 

[SOYER]

@VisualLab jesteś jak Vari Master L😁

[H1M4W4R1]

Sorki za tak późną odpowiedź, ale miałem przerwę od wypowiadania się w sieci...

Dnia 4.02.2022 o 23:52, VisualLab napisał:

1. Czy w kod programu dałoby się nieco uprościć (albo: uczynić nieco przejrzystszym) przez zastosowanie tablic przeglądowych? Na przykład w funkcjach: "init_led" czy "display". Te tablice można by umieścić w pliku nagłówkowym.

Tak, da się, ale byłem na to zbyt leniwy w momencie pisania tego kodu (łatwiej było kliknąć kilka razy TAB)

#include <stdio.h>
#include <pico/multicore.h>
#include "pico/stdlib.h"

// Letters
#define L_A 6
#define L_B 8
#define L_C 14
#define L_D 16
#define L_E 17
#define L_F 7
#define L_G 13
#define L_DP 15

// Transistors
#define L_0 11
#define L_1 9
#define L_2 10
#define L_3 12

// Contactron input
#define STATUS 26

int T_LETTERS[] = {L_A, L_B, L_C, L_D, L_E, L_F, L_G, L_DP};
int T_TRANSISTORS[] = {L_0, L_1, L_2, L_3};

int T_DICTIONARY[] = {
        0b111000000, // 0
        0b111111001, // 1
        0b110100100, // 2
        0b110110000, // 3
        0b110011001, // 4
        0b110010010, // 5
        0b110000010, // 6
        0b111111000, // 7
        0b110000000, // 8
        0b110010000  // 9
};

// Internal display storage
int display0;
int display1;
int display2;
int display3;
int counter = 0;

// Last tick
uint64_t lastTick = 0x0;

void gpio_callback(uint gpio, uint32_t events){
    uint64_t time = time_us_64() / 1000; // Get time (ms)
    if(time - lastTick > 500) // If time elapsed
    {
        counter++; // Execute
        lastTick = time; // Reset counter
    }
}

void init_led()
{
    // Initialize letters GPIO
    for(int q = 0; q < sizeof(T_LETTERS)/sizeof(int); q++)
    {
        gpio_init(T_LETTERS[q]);
        gpio_pull_up(T_LETTERS[q]);
        gpio_set_dir(T_LETTERS[q], GPIO_OUT);
    }

    // Disable Dot Point
    gpio_put(L_DP, true);

    // Initialize transistors GPIO
    for(int q = 0; q < sizeof(T_TRANSISTORS)/sizeof(int); q++)
    {
        gpio_init(T_TRANSISTORS[q]);
        gpio_set_dir(T_TRANSISTORS[q], GPIO_OUT);
    }

    // Status Pin
    gpio_init(STATUS);
    gpio_set_dir(STATUS, GPIO_IN);

    // Setup IRQ on main core
    gpio_set_irq_enabled_with_callback(STATUS, GPIO_IRQ_EDGE_FALL, true, gpio_callback);
}

void display(int pos, char value)
{
    // Translate value to display
    int result = T_DICTIONARY[value];

    // Set digit display
    for(int number = 0; number < sizeof(T_LETTERS) / sizeof(int); number++)
    {
        gpio_put(T_LETTERS[number], (result & (1 << number)) > 0);
    }

    // Switch transistors
    for(int number = 0; number < sizeof(T_TRANSISTORS) / sizeof(int); number++)
        gpio_put(T_TRANSISTORS[number], pos == number);
}

// Secondary core - display numbers on LCD in infinite loop
void core1_func(){
    while(true){
        display(0, display0);
        sleep_us(100);
        display(1, display1);
        sleep_us(100);
        display(2, display2);
        sleep_us(100);
        display(3, display3);
        sleep_us(100);
    }
}

// Display number - send number to secondary core
void display_number(int number){
    display0 = number / 1000;
    number -= display0 * 1000;
    display1 = number / 100;
    number -= display1 * 100;
    display2 = number / 10;
    number -= display2 * 10;
    display3 = number;
}

int main()
{
    stdio_init_all();

    // Initialize GPIO
    init_led();

    // Display displayer ;)
    multicore_launch_core1(core1_func);

    // Infinite loop display for current counter value
    while(true)
    {
        display_number(counter);
    }

    return 0;
}

To dla potomnych...

Dnia 4.02.2022 o 23:52, VisualLab napisał:

2. Czym różnią się typy: "uint" i "uint32_t"? Występują na przykład w funkcji "gpio_callback(uint gpio, uint32_t events)". Pytam dlatego, bo w kodzie SDK⁽¹⁾ dla RPi Pico w niektórych funkcjach występują takie deklaracje argumentów (tj. w nagłówku funkcji pojawia się obok siebie te dwa typy). Wydaje mi się, że zarówno "uint" jak i "uint32_t" jest aliasem do "unsigned int" i jest 4-ro bajtowy (może w jakichś starych kompilatorach C było inaczej). Ujednolicenie typów dałoby spójniejszy kod.

Jedyna różnica jest taka, że uint32_t oznacza, że typ ma zawsze 32 bity, w przypadku uint może to być 16 lub 32 (w przyszłości pewnie 64, ale w to raczej wątpię).

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[Ogyb]

No wiec tak, czy pico jest ok? Jest, da się je kupić łatwiej jak atmege8 do tego jeżeli kupujemy jako sam układ scalony wyjdzie duzo taniej od mega8. Czy jest taki ach och i super? No nie do wszystkich zastosowań:) przykładowo robiąc to na stm32 (mowie o seriach z literą G które jeszcze czasami da się kupić w cenie ponizej 10zł) można to zrobić na 2 licznikach bez większego użycia programu. Wiec "przewaga" tych rdzeni dodatkowych umiera, zreszta również bez liczników wykorzystując 0.1% mocy nie potrzebujemy drugiego rdzenia.

 

Ale np jeżeli chcemy wykorzystać LCD kolorowy to współczynnik moc obliczeniową/cena jest jak najbardziej pozytywny aktualnie. Również cena za pamięć wychodzi bardzo korzystnie.

 

Również nowe układy atmega i attiny sa dużo tańsze od swoich odpowiedników, a mamy do dyspozycji coś w rodzaju fpga na wejściu do scalaka. Dzisiaj kupiłem 14 nozkowe tinny po 2.30zł/sztuka.

[H1M4W4R1]

20 minut temu, Ogyb napisał:

No wiec tak, czy pico jest ok? Jest, da się je kupić łatwiej jak atmege8 do tego jeżeli kupujemy jako sam układ scalony wyjdzie duzo taniej od mega8. Czy jest taki ach och i super? No nie do wszystkich zastosowań:) przykładowo robiąc to na stm32 (mowie o seriach z literą G które jeszcze czasami da się kupić w cenie ponizej 10zł) można to zrobić na 2 licznikach bez większego użycia programu. Wiec "przewaga" tych rdzeni dodatkowych umiera, zreszta również bez liczników wykorzystując 0.1% mocy nie potrzebujemy drugiego rdzenia.

Grzecznie pozwolę sobie zacytować siebie samego:

[sarkazm] Równie dobrze mogłem to zrobić na komputerze kwantowym z NASA... Też by działało... [/sarkazm]

[VisualLab]

Kwestię „czy RPi Pico jest OK?” można rozpatrywać z kilku punktów widzenia. Oczywiście odnosząc się do tematu założonego przez autora projektu. W przeciwnym wypadku będziemy mieli do czynienia z luźnymi dygresjami, całkowicie niepowiązanymi z tematem.

1. Czy RPi Pico jest OK pod względem sprzętowym (zasoby sprzętowe mikrokontrolera)? Tu wg mnie nie ma zastrzeżeń. Układ jest nieco więcej niż wystarczający, ale trudno mówić o jakimś „przewymiarowaniu” projektu. Tak by było, gdyby został użyty np. komputer w typu SBC (np. RPi, Up Squared) czy jakiś NUC (to oczywiście już przejaskrawiony przypadek). A tego w projekcie nie było.

2. Czy RPi Pico jest OK pod względem cenowym? Tak. Porównując jego cenę do podobnych do niego mikrokontrolerów (zasoby sprzętowe), cena jest atrakcyjna. Oczywiście pewnie można by było użyć prostszego mikrokontrolera. Ale jeśli mamy w szufladzie egzemplarz, który spełnia założone wymagania projektu, to pod względem cenowym projekt jest OK. Bardzo ważne w tym przypadku jest to, że autor zbudował 1 egzemplarz. Tu jak wiadomo, największy koszt stanowi stworzenie programu. Gdyby autor chciał sprzedawać wiele egzemplarzy swojego urządzenia (dajmy na to 100 sztuk, albo więcej), to mnie wydaje się oczywiste, że pierwszą rzecz jaką by zrobił, to policzył koszty. I reszta decyzji projektowych byłaby znacząco od tego uzależniona. Ale 100 sztuk (albo więcej), to już oznaczałoby nie projekt autorski ale zwyczajną produkcję. A takiej sytuacji na ogół dąży się do minimalizacji kosztów produkcji. Oczywiście przed produkcją i tak wystąpiłby etap tworzenia prototypu.

3. Czy RPi Pico jest OK pod względem oprogramowania zaproponowanego przez fundację? To jest (moim zdaniem) dyskusyjne. Ale tu ważne zastrzeżenie. To nie ma nic wspólnego z tematem owijarki. Ma za to wiele wspólnego z decyzjami ludzi z fundacji RPi.

Kwestię oprogramowania zaproponowanego przez fundację trzeba by rozdzielić na dwie grupy: (1) SDK i (2) narzędzia (edytor kodu, kompilator, budowanie projektu). Zatem, zgodnie z klasyfikacją podaną w pierwszym zdaniu mojego postu, wszystko co znajduje się poniżej, to maja luźna dygresja nie związana z tematem projektu.

To co nie podoba mi się w SDK, to konieczność użycia CMake. Konieczność ręcznego grzebania w plikach budowania projektu to spora przesada. Gdyby to dotyczyło projektów komercyjnych, pisanych przez doświadczonych programistów, to da się to usprawiedliwić. Ale RPi podobno ma cel edukacyjny (sam pomysł mikrokontrolera ogólnie jest OK). Nie chodzi jednak o to, że CMake wymaga większej wiedzy. W rzeczywistości jest to żywa skamielina, taka „latimeria informatyki”. CMake jest po prostu upierdliwe w użyciu. Czy rzeczywiście nie było lepszego narzędzia budowania projektów?

Druga rzecz, to edytor kodu. Wybrane zostało coś, co jest czymś w rodzaju "krokodyla z wodogłowiem i niedorozwojem kończyn". Od pewnego czasu trwa jakaś chora moda na tworzenie programów w JavaScript (Electron, jNode). Dziwaczny trend na pseudo-desktopowe „natywne” programy „wygniatane” w językach skryptowych (pierwotnie nie dostosowanych do tego celu). Ja rozumiem, że ludzie w fundacji RPi chcieli użyć edytora open source. Więcej, uważam, że taki pomysł jest z wielu powodów jest prawidłowy (kwestie kosztów, kwestie wizerunkowe, itp.). Ale czy fundacja nie mogła użyć czegoś lepszego? Czegoś nie uzależnionego od korporacyjnego giganta, który może mieć swoje fochy i zachcianki? Są przecież: Code::Blocks, Geany, NetBeans. Oczywiście, że trzeba by je dostosować. Tak postąpiła fundacja dostarczająca Arduino. Oczywiście to są pewne koszty. Ale ułatwiłoby to ludziom życie. A na pewno dużo lepiej przyczyniłoby się do popularyzacji mikrokontrolera RPi Pico.

[ethanak]

Jakie narzędzia, jaki edytor?

cmake, make i edytor jaki chcesz z notepadem na czele.

No, chyba że to coś co udaje edytor w Arduino IDE uważasz za super zajefajny... Przecież możesz pisać w CB czy czym tam chcesz. Ja używam Geany od lat zarówno do Pico, jak i całej reszty tałatajstwa które programuję zarówno amatorsko jak i zawodowo. I jakoś nie spotkałem się z sytuacją, że ktoś na mnie wymusi stosowanie innego edytora (z Arduino IDE włącznie)

[Chumanista]

Że się jeszcze nie pojawiło a widzę robimy festiwal "a ja bym użył":

Moim zdaniem najbardziej eleganckie rozwiązanie małej trwałej pamięci która Po Prostu Działa™ jest FRAM, można dostać za euro-dwa parę kilobajtów i zapisywać praktycznie natychmiast ile się chce bez przejmowania się zużyciem.

A u mnie aktualnie w dwóch projektach ląduje ESP32 pomimo że nie użyję radia bo kosztują 12zł i są ciągle dostępne.

[Ogyb]

RP2040 kosztuje 4zł;) a powracając do tematu pamięci - zwykła 24c02 wytrzyma ponad 40 tyś balików przy 24 owinięciach😉 owijarka może tyle nie wytrzymać. Ale prawdopodobieństwo braku zasilania jest nikłe, i tak owijarka poleci kilka obrotów nim zauważy "obsługa", że zgasło. Wiec jest to bez większego sensu.

 

Najlepszym układem do takiego zastosowania jest... PCF8583 😉 ustawiamy jako licznik i sam liczy, nie zapomina jeżeli ma baterie lub kondensator podtrzymujący, liczy mimo braku głównego zasilania. Ma RAM do zapisu dodatkowych pierdoł z podtrzymaniem.

[VisualLab]

Dnia 13.03.2022 o 14:08, ethanak napisał:

Jakie narzędzia, jaki edytor?

cmake, make i edytor jaki chcesz z notepadem na czele.

No, chyba że to coś co udaje edytor w Arduino IDE uważasz za super zajefajny... Przecież możesz pisać w CB czy czym tam chcesz. Ja używam Geany od lat zarówno do Pico, jak i całej reszty tałatajstwa które programuję zarówno amatorsko jak i zawodowo. I jakoś nie spotkałem się z sytuacją, że ktoś na mnie wymusi stosowanie innego edytora (z Arduino IDE włącznie)

Tak, nadal podoba mi się Arduino IDE 🙂 Dla początkujących jest wystarczający. Ma pewne cechy (zalety), których nie ma VSCode. Pewnie, że można użyć innego edytora (tak właśnie robię). Ale początkujący potrzebują pewnych ułatwień. Jak przestaną być początkujący (czytaj: nabiorą wprawy, doświadczenia, także wiedzy teoretycznej), to sobie potem coś innego wybiorą. Dygresja dotyczyła tego, co początkujący dostaje na starcie. Początkujący raczej nie programuje zawodowo.

Co do wymuszania. Pewnie, że nikt tego nie wymusza. Wszak fundacja RPi to nie mafia reketierów a użytkownicy RPi Pico to nie zamożni restauratorzy 🙂

Wracając do narzędzi - trzeba jednak rozróżnić: (a) rozwiązanie jakie jest proponowane w celach edukacyjnych kontra (b) rozwiązanie przemysłowe albo dla naprawdę doświadczonych programistów. Druga kwestia to jakby nie patrzeć jest rok 2022. A fundacja RPi proponuje rozwiązania rodem z lat 1985-1990. Taki sposób pracy można lapidarnie (i może nieco złośliwie) skwitować:

"nakurwiaj w klawiaturę - tak jest dobrze"

Stąd moje utyskiwanie co do CMake czy VSCode. Ja się zgadzam, że programowanie wymaga cierpliwości (i "wklepywania" kodu 🙂 Ale są jakieś granice. Czas jest cenny. Skoro da się przerzucić część pracy na komputer, to dlaczego tego nie robić? Nużące, powtarzalne czynności jak najbardziej należy powierzyć komputerowi (czyt. oprogramowaniu). A na pewno te zaproponowane przez fundację nie automatyzują wystarczająco tych nużących, rutynowych czynności.

Zresztą podobne podejście było (i nadal jest) promowane przez fundację w przypadku Raspbiana (teraz: Raspberry OS). Konsola, konsola i jeszcze raz konsola. I to jeszcze na koncie zwykłego użytkownika. Za każdym razem - "sudo" (no dobra, można się zalogować jako root w konsoli, ale to niewiele ułatwia). Gdyby to dotyczyło urządzenia dostępnego publicznie, które ma być zabezpieczone przez użytkownikami, to jak najbardziej byłoby to słuszne. Tylko, że RPi to komputerek do eksperymentów! Nie każdy robi z niego serwer z publicznie dostępnymi zasobami. Więcej - RPi było (i nadal jest) promowane głównie jako SBC do eksperymentów przede wszystkim z elektroniką. I słusznie. Mnie się ten pomysł bardzo podobał (i nadal mi się podoba). Sterowanie elektroniką w domu albo w jakimś urządzeniu. Tylko z tym OS'em to tak raczej słabo wyszło. Wiem, wiem - "to se dostosuj Linux'a pod swoje potrzeby". A pewnie. Ale nie o to w tym chodzi. Chodzi o "progress", czy to w nauce, zdobywaniu doświadczenia czy w realizacji projektu [1].

A i jeszcze jedno - praca na koncie roota w GUI jest jak najbardziej OK, gdy się to robi na własnym, całkowicie prywatnym komputerku, używanym celowo do eksperymentów. Niebezpieczne, to może być połykanie arszeniku, skakanie "na główkę" do płytkiego strumienia z wysokości 10 metrów czy sikanie pod wiatr 🙂

Jeszcze wracając do SDK RPi Pico. Kod w tych plikach rzeczywiście jest "edukacyjny". Taka malutka próbka (są "lepsze"):

*rxbuf++ = (uint8_t)ssi_hw->dr0;

I "w pi...du" makr w większości plików. To nie uczy programowania tylko partactwa. I teraz człowiek się zastanawia - czy ludzie co napisali SDK, to jakieś "paparuchy" akademickie (znające podstawy ale komplikujące bez potrzeby rzeczy proste), czy tzw. "nadęte buce" chcące się pochwalić tzw. "sprytnym kodem" na zasadzie: "a niech widzą jaki to ja jestem bystry i doświadczony, w jednej linijce to wszystko zmieszczę". Tylko, że to nie jest programowanie - to grypsowanie. Skoro RPi Pico ma cel edukacyjny, to wskazane byłoby, żeby kod też był przyzwoity. Przecież wielu ludzi będzie chciało się przyjrzeć zawartości plików SDK dla nauki czy chociażby z ciekawości (i z pewnością to robią - na przykład ja). Na pewno ludzie z fundacji to sprawdzali i testowali. Ale kompilujący się i działający kod można różnie napisać. I tu jest właśnie pies pogrzebany.

---

[1] Problemem jest to, że Linux ma bardzo archaiczną architekturę, z korzeniami gdzieś w okolicach 1985 roku. Niestety nie ma innego powszechnie dostępnego (z kodem źródłowym) OS'a do eksperymentowania z SBC. Zatem lepszy taki, niż żaden.

[ethanak]

2 minuty temu, VisualLab napisał:

podoba mi się Arduino IDE 🙂 Dla początkujących jest wystarczający

Wybitnie wystarczający. Szczególnie, jeśli ktoś screenreadera używa...

[VisualLab]

55 minut temu, ethanak napisał:

Wybitnie wystarczający. Szczególnie, jeśli ktoś screenreadera używa...

A z VSCode, Geany (czy jakimkolwiek edytorem kodu działającym w GUI) czytniki dla niewidomych sobie dobrze radzą? Czy to o tą nieszczęsną Javę się rozchodzi?

[ethanak]

9 godzin temu, VisualLab napisał:

A z VSCode, Geany (czy jakimkolwiek edytorem kodu działającym w GUI) czytniki dla niewidomych sobie dobrze radzą?

nie próbowałem VSC (jakoś go dziwnie nie lubię) ale Geany - przynajmniej pod Linuksem - działa bardzo dobrze (zdanie mojego znajomego który akurat Geany w takiej konfiguracji używa). Sprawdzę później VSC + Orca.

W tym tworze edytoropodobnym Arduino IDE nawet JAWS się nie może odnaleźć (tzn. reszta jest w miarę OK, ale edytor nie), Orca w ogóle nie widzi okna IDE.