RTV forum PL | NewsGroups PL

AVR po latach

NOWY TEMAT

elektroda NewsGroups Forum Index - Elektronika Polska - AVR po latach

Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next

Grzegorz Niemirowski
Guest

Mon Nov 15, 2021 6:57 pm   



heby <heby_at_poczta.onet.pl> napisał(a):
Quote:
1) Możesz zostawić środowiko arduino i używać
Eclipse/Netbeans/QtCreator/Atom/itd jako edytora.

Idąc za ciosem można zrezygnować z Arduino zupełnie.

Quote:
2) Debugowanie jest praktycznie niemożliwe bez emulacji sprzetu. Często ta
emulacja sprzetu jest milion razy trudniejsza. Dlatego wymysliliśmy
techniki pisania kodu, które praktycznie redukują potrzebę debugowania na
*prawdziwym* targecie, asymptotycznie do zera. Zaryzykuje że poprawnie
napisany program w języku C/C++ będzie wymagał debugowania w emulatorze
CPU w mniej niż promilu przypadków. Za to będzie znakomicie debugował się
na hoście.

Moje doświadczenia są zgoła odmienne. Nie wiem do czego miałby mi być
potrzebny emulator CPU. Kod pracuje w jakimś urządzeniu i komunikuje się z
innymi układami. Potrzebna jest możliwość sprawdzania co się dzieje w
rzeczywistym układzie. Tu przydaje się oscyloskop, analizator stanów
logicznych oraz debuger.

Quote:
2. Biblioteki pisane na kolanie
Nikt nie każe z nich korzystać.

Więc kłania się punkt 1 - można zrezygnować z Arduino całkowicie, skoro nie
oferuje żadnej dużej wartości.

Quote:
W 99% programów pojawi się taki setup/loop.

Pojawia się, ale jest to sztuczne zaciemnianie.

Quote:
Problem w tym że nie padło "poważne zastosowania" u wątkotwórcy, za to
padło ATTINY. Co niejako stoi bokiem do koncpecji "profesjonalnych IDE"
skoro kod nie jest większy niż max kilka stron na ekranie i może być
pisany w Arduino czy czymkolwiek innym, wliczając notatnik. Choć tak nisko
bym nie upadał.

Nawet krótki kod wolę pisać w wygodnym IDE.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

heby
Guest

Mon Nov 15, 2021 7:07 pm   



On 15/11/2021 18:57, Grzegorz Niemirowski wrote:
Quote:
1) Możesz zostawić środowiko arduino i używać
Eclipse/Netbeans/QtCreator/Atom/itd jako edytora.
Idąc za ciosem można zrezygnować z Arduino zupełnie.

Dokładnie tak. Przecież to był tylko pretekst do ewaluacji
"hobbystyczne" vs "profesjonalnie" gdzie oba, to tylko inna odmiana
dziadostwa, typowego dla embedded.

Quote:
2) Debugowanie jest praktycznie niemożliwe bez emulacji sprzetu.
Często ta emulacja sprzetu jest milion razy trudniejsza. Dlatego
wymysliliśmy techniki pisania kodu, które praktycznie redukują
potrzebę debugowania na *prawdziwym* targecie, asymptotycznie do zera.
Zaryzykuje że poprawnie napisany program w języku C/C++ będzie wymagał
debugowania w emulatorze CPU w mniej niż promilu przypadków. Za to
będzie znakomicie debugował się na hoście.
Moje doświadczenia są zgoła odmienne. Nie wiem do czego miałby mi być
potrzebny emulator CPU. Kod pracuje w jakimś urządzeniu i komunikuje się
z innymi układami. Potrzebna jest możliwość sprawdzania co się dzieje w
rzeczywistym układzie. Tu przydaje się oscyloskop, analizator stanów
logicznych oraz debuger.

Prawie nigdy nie jest potrzebne, przy prawidłowych abstrakcjach na
poziomie kodu i unit testach. Bez najmniejszego problemu mogę napisać
kod obsługujący, powiedzmy, modbusa przy pokryciu po stronie hosta na
poziomie 95% coverage, gdzie po stronie AVR znajduja się juz tylko gołe
read/write do rejestrów uartu. Nie wiem gdzie tu miejsce dla
oscyloskopu, to ostateczność.

To kwestia bardziej jakości kodu i umiejętności pisania abstrakcyjnego,
ale blisko sprzetu.

Zaznaczam, że wbrew opini niedzielnych programistów C++, ta abstrakcja
przychodzi z zerowym obciązeniem dla kodu wynikowego, nie pojawi się
nawet instrukcja więcej.

Quote:
2. Biblioteki pisane na kolanie
Nikt nie każe z nich korzystać.
Więc kłania się punkt 1 - można zrezygnować z Arduino całkowicie, skoro
nie oferuje żadnej dużej wartości.

Dokładnie do tego dążę.

Quote:
W 99% programów pojawi się taki setup/loop.
Pojawia się, ale jest to sztuczne zaciemnianie.

Akurat to jest prawdziwe rozjaśnianie intencji ;)

Quote:
Problem w tym że nie padło "poważne zastosowania" u wątkotwórcy, za to
padło ATTINY. Co niejako stoi bokiem do koncpecji "profesjonalnych
IDE" skoro kod nie jest większy niż max kilka stron na ekranie i może
być pisany w Arduino czy czymkolwiek innym, wliczając notatnik. Choć
tak nisko bym nie upadał.
Nawet krótki kod wolę pisać w wygodnym IDE.

I tu wchodzi jakiś tuzin znakomitych środowisk do pisania w C/C++. Bo
tylko tyle potrzeba w 99% wypadków pisania kodu embedded.

Co innego gdy to jest hobbystyczne pisanie na ATTINY. Tam można sobie
pomigać diodą w symulatorze, wiadomo. Ale czy to nie jest aby własnie
"hobbystyczne"?

Grzegorz Niemirowski
Guest

Mon Nov 15, 2021 7:19 pm   



heby <heby_at_poczta.onet.pl> napisał(a):
Quote:
Prawie nigdy nie jest potrzebne, przy prawidłowych abstrakcjach na
poziomie kodu i unit testach. Bez najmniejszego problemu mogę napisać kod
obsługujący, powiedzmy, modbusa przy pokryciu po stronie hosta na poziomie
95% coverage, gdzie po stronie AVR znajduja się juz tylko gołe read/write
do rejestrów uartu.

Wiadomo, że można (i powinno się) pisać na podstawie dokumentacji i bez
uruchamiania kodu po każdej napisanej linijce. Chodzi o to, że praktycznie
zawsze coś potem nie działa i wcale niekoniecznie z Twojej winy.

Quote:
Nie wiem gdzie tu miejsce dla oscyloskopu, to ostateczność.

Nie tylko Modbus jest na świecie. Poza tym mówimy o styku programowania z
elektroniką. Jeśli oscyloskop nie jest potrzebny, to jest to albo prosty
projekt albo embedded wysokopoziomowe (odległe od sprzętu).

Quote:
To kwestia bardziej jakości kodu i umiejętności pisania abstrakcyjnego,
ale blisko sprzetu.
Zaznaczam, że wbrew opini niedzielnych programistów C++, ta abstrakcja
przychodzi z zerowym obciązeniem dla kodu wynikowego, nie pojawi się nawet
instrukcja więcej.

Wiadomo :)

W każdym razie ta część wątku zaczęła się od emulatora CPU. Arduino i tak go
nie ma, więc nie ma co tu drążyć :)

Quote:
I tu wchodzi jakiś tuzin znakomitych środowisk do pisania w C/C++. Bo
tylko tyle potrzeba w 99% wypadków pisania kodu embedded.

Wracamy więc do początku wątku. Jeśli ktoś wybiera znakomite środowisko
zamiast Arduino IDE, to nie ze względów religijnych ale dlatego, że jest
ono... znakomite :)

--
Grzegorz Niemirowski
https://www.grzegorz.net/

heby
Guest

Mon Nov 15, 2021 7:34 pm   



On 15/11/2021 19:19, Grzegorz Niemirowski wrote:
Quote:
Prawie nigdy nie jest potrzebne, przy prawidłowych abstrakcjach na
poziomie kodu i unit testach. Bez najmniejszego problemu mogę napisać
kod obsługujący, powiedzmy, modbusa przy pokryciu po stronie hosta na
poziomie 95% coverage, gdzie po stronie AVR znajduja się juz tylko
gołe read/write do rejestrów uartu.
Wiadomo, że można (i powinno się) pisać na podstawie dokumentacji

Nie, dalej nie rozumiesz. Ja nie mówie o pisaniu zgodnie z dokumentacją
i wymagania nieomylności.

Ja mówie o pisaniu kodu w sposób, który redukuje potrzebę debugowania w
sprzęcie do zera lub blisko zera. To wymaga innych technik
programowania, niż stosowane w embedded, w szczególności przeproszenia
sie z C++ (przez co czeka nas przeczekanie obecnego pokolenia
programistów embedded, jako że to problem białkowy).

Quote:
uruchamiania kodu po każdej napisanej linijce. Chodzi o to, że
praktycznie zawsze coś potem nie działa i wcale niekoniecznie z Twojej
winy.

Jest śladowo prawdopodobne, abyś dał radę znaleźć nowy bug w AVR.
Miliony programistów Arduino raczej by go znalazły.

Quote:
Nie wiem gdzie tu miejsce dla oscyloskopu, to ostateczność.
Nie tylko Modbus jest na świecie. Poza tym mówimy o styku programowania
z elektroniką. Jeśli oscyloskop nie jest potrzebny, to jest to albo
prosty projekt albo embedded wysokopoziomowe (odległe od sprzętu).

Ani jedno ani drugie. Możesz napisać skomplikowany projekt blisko
sprzetu, w 95% pokryty testami po stronie komputera dev. To nie jest
rocket science. To normalna praktyka pisania kodu na dowolną platoformę,
od superkomputerów do attiny.

Debuggery hardwareowe to ostatecznośc. Jesli podczas pisania kodu musisz
ich używać, to masz kiepsko napisany kod.

Zgodzę się, że czasami mogą być przydatne przy uruchamianiu kodu, ale
zazwyczaj to oznacza, że coś jest spieprzone i nieprzetestowane
wcześniej, lub błąd masz w konkretyzacji abstrakcji (gdzie zwyczajowo
kodu wiele nie ma).

Quote:
W każdym razie ta część wątku zaczęła się od emulatora CPU. Arduino i
tak go nie ma, więc nie ma co tu drążyć Smile

Nie bez powodu. Dzięki temu, że ma gotowe bibliteki, taki debug jest
mało potrzebny.

Quote:
I tu wchodzi jakiś tuzin znakomitych środowisk do pisania w C/C++. Bo
tylko tyle potrzeba w 99% wypadków pisania kodu embedded.
Wracamy więc do początku wątku. Jeśli ktoś wybiera znakomite środowisko
zamiast Arduino IDE, to nie ze względów religijnych ale dlatego, że jest
ono... znakomite Smile

Ale nie jestem przekonany, czy środowiska do embedded są znakomite. Jak
na razie po kontakcie z kilkoma na przestrzeni 20 lat, uciekam na same
słowa "embedded IDE".

Grzegorz Niemirowski
Guest

Mon Nov 15, 2021 7:57 pm   



heby <heby_at_poczta.onet.pl> napisał(a):
Quote:
Jest śladowo prawdopodobne, abyś dał radę znaleźć nowy bug w AVR. Miliony
programistów Arduino raczej by go znalazły.

Oczywiście nie mówię o bugach w AVR. Chodzi o to, że urządzenie nie składa
się z samego MCU. Masz też różne inne układy, które mogą się zachowywać
inaczej niż myślałeś lub mieć błędy. Przykładowo UART w Raspberry Pi wysyłał
na początku transmisji dodatkową szpilkę, która mogła być traktowana jako
bit startu. Nie było to nigdzie opisane. Pracując w embedded takie i inne
kwiatki spotyka się cały czas.

Quote:
Debuggery hardwareowe to ostatecznośc. Jesli podczas pisania kodu musisz
ich używać, to masz kiepsko napisany kod.

To jest akademicka teoria. Powiedz twórcom GDB, że zmarnowali swój czas Smile
Debuger jest normalnym narzędziem i sięganie po niego nie musi wcale źle
świadczyć o programiście. Jego brak jest ograniczeniem środowiska.

Quote:
Nie bez powodu. Dzięki temu, że ma gotowe bibliteki, taki debug jest mało
potrzebny.

Piszesz o nich jak o bibliotekach libc. Tymczasem mają one nieraz błędy i
słabą dokumentację.

Quote:
Ale nie jestem przekonany, czy środowiska do embedded są znakomite. Jak na
razie po kontakcie z kilkoma na przestrzeni 20 lat, uciekam na same słowa
"embedded IDE".

No właśnie Smile Tym bardziej Arduino IDE :)

--
Grzegorz Niemirowski
https://www.grzegorz.net/

heby
Guest

Mon Nov 15, 2021 8:22 pm   



On 15/11/2021 19:57, Grzegorz Niemirowski wrote:
Quote:
Jest śladowo prawdopodobne, abyś dał radę znaleźć nowy bug w AVR.
Miliony programistów Arduino raczej by go znalazły.
Oczywiście nie mówię o bugach w AVR. Chodzi o to, że urządzenie nie
składa się z samego MCU. Masz też różne inne układy, które mogą się
zachowywać inaczej niż myślałeś lub mieć błędy. Przykładowo UART w
Raspberry Pi wysyłał na początku transmisji dodatkową szpilkę, która
mogła być traktowana jako bit startu. Nie było to nigdzie opisane.
Pracując w embedded takie i inne kwiatki spotyka się cały czas.

Zgadza się. Dlatego psu na budę debugger softwareowy w roli debuger
hardwareowego. To najzwyczajneij zupełnie inne zagadnienie.

Quote:
Debuggery hardwareowe to ostatecznośc. Jesli podczas pisania kodu
musisz ich używać, to masz kiepsko napisany kod.
To jest akademicka teoria. Powiedz twórcom GDB, że zmarnowali swój czas

Obserwacja z pola bitwy: prawidłowe pisanie kodu minimalizuje potrzebę
używania debuggera. Do zera? Nie. Blisko zera? Tak. Mówiąc "pisanie
kodu" mam na myśli testowanie go a dopiero potem pisanie. Zwyczajowo
waga unit testów znaczaco przekracza wagę kodu produkcyjnego.

Obserwacja z innego pola: debuggery softwareowe nie nadają się do
*rzeczywistych* systemów hardwareowych gdzie istnieją zalezności
czasowe. Do tego bezpieczniej jest stosować symulatory logiczne z
emulacją cpu i peryferiów. Tylko wtedy nie wiadomo czy bug jest u mnie
czy w emulacji. I takie symulatory za darmo się nie rozdają.

Ja ten problem rozwiązywałem kiedyś kradnąć rdzeń AVR z projektu MAME i
dorabiając ręcznie napisany emulator pewnego peryferium, dzięki czemu
udało się namierzyć buga, ale to jednorazowy wyskok, raczej desperacja.

Quote:
Smile Debuger jest normalnym narzędziem i sięganie po niego nie musi wcale
źle świadczyć o programiście. Jego brak jest ograniczeniem środowiska.

Nie o tym mowa.

W środowisku softwareowym, debugger to normalne narzędzie z łatwo
(zazwyczaj) powtarzalnymi przypadkami.

W środowisku hardwareowym jest to narzędzie skrajnie trudne do użycia.
Wyobraź sobie debugowanie przez JTAG procesora, który ma wysyłać co
milisekundę heartbeat do watchdoga zewnątrznego. Zatrzymujesz go na
breakpoincie i jesteś umarty.

Albo symulujesz całość *systemu* hardwareowego i tam debugujesz w
komfortowych warunkach, albo masz na głowie niezliczone ilosci problemów
z faktem że czas mimo zatrzymania programu pędzi dalej, przerwania się
nie obsługują, bufory się przepełniają, ciekłe kryształy się elektrolizują.

gdb to nie jest narzędzie do debugowania w hardware, poza śmiesznie
prostymi przypadkami debugowania kodu wysokopoziomowego. Co akurat robi
się prawie zawsze na maszynei dev, a nie w hardware.

Quote:
Nie bez powodu. Dzięki temu, że ma gotowe bibliteki, taki debug jest
mało potrzebny.
Piszesz o nich jak o bibliotekach libc. Tymczasem mają one nieraz błędy
i słabą dokumentację.

Zupełnie jak wiele kawałków hardware, używanych codziennie. Ogólnie
świat hardware to nic specjalnie pewnego. Więc niejako karę za hobby
embedded niech będzie czujnośc, że wszędzie czają się bugi, a te
hardwareowe są najweselsze.

Quote:
Ale nie jestem przekonany, czy środowiska do embedded są znakomite.
Jak na razie po kontakcie z kilkoma na przestrzeni 20 lat, uciekam na
same słowa "embedded IDE".
No właśnie Smile Tym bardziej Arduino IDE Smile

Od Arduino jak najdalej. Nie miej wrażenia, że jesli zapytałem o
religijnośc poglądów na Arduion, to jestem fanem. To Qpa. Ale pozwole
sobie na jeden komplement: mimo wymachiwania pięściami przez 60latków z
embedded, wprowadził tylnymi drzwiami C++ do świata uC. Podziękowania
się należą, nowe pokolenie programistów embedded będzie dzieki temu
bardziej ateistyczne.

Atlantis
Guest

Tue Nov 16, 2021 9:03 am   



On 15.11.2021 17:46, heby wrote:

Quote:
Pod spodem jest ten sam kompilator gcc, używany w projektach komercyjnych.

Co więcej, Arduino zrobiło jedną, bardzo ważną rzecz - wprowadziło na
większą skalę obiektowość do świata mikrokontrolerów. Właściwie
wszystkie biblioteki dla tego ekosystemu są pisane jako klasy C++, ze
wszystkimi zaletami wynikającymi z dziedziczenia. Na przykład biblioteki
graficzne są definiowane jako warstwa abstrakcji, z interfejsem do
operacji I/O w formie metod czysto wirtualnych. Te metody potem
implementuje autor sterownika wyświetlacza, który dziedziczy po
bibliotece graficznej.
I nie żebym miał cokolwiek przeciwko tradycyjnemu C - sam piszę kod do
większości swoich projektów w ten sposób. Jednak mamy XXI wiek, w MCU
nie trzeba już liczyć bajtów i cykli, a dzieciakom dzisiaj zaczynającym
zabawę z programowaniem w przyszłości prędzej przyda się umiejętność
sprawnego pisania obiektowego kodu.

Grzegorz Niemirowski
Guest

Tue Nov 16, 2021 11:26 am   



heby <heby_at_poczta.onet.pl> napisał(a):
Quote:
Zgadza się. Dlatego psu na budę debugger softwareowy w roli debuger
hardwareowego. To najzwyczajneij zupełnie inne zagadnienie.

Zgadza się. Ja tylko piszę, że debugger jest przydatny i wolę środowisko,
które go ma od środowiska, którego go nie ma. Czy się pisze na AVR czy jakiś
Threadripper od czasu do czasu trzeba sprawdzić jaki jest stan zmiennych,
rejestrów czy też je zmodyfikować. Z wielu różnych powodów, nie dlategto, że
ktoś użył za mało abstrakcji.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

Grzegorz Niemirowski
Guest

Tue Nov 16, 2021 11:51 am   



Atlantis <marekw1986NOSPAM_at_wp.pl> napisał(a):
Quote:
Co więcej, Arduino zrobiło jedną, bardzo ważną rzecz - wprowadziło na
większą skalę obiektowość do świata mikrokontrolerów. Właściwie wszystkie
biblioteki dla tego ekosystemu są pisane jako klasy C++, ze wszystkimi
zaletami wynikającymi z dziedziczenia. Na przykład biblioteki graficzne są
definiowane jako warstwa abstrakcji, z interfejsem do operacji I/O w
formie metod czysto wirtualnych. Te metody potem implementuje autor
sterownika wyświetlacza, który dziedziczy po bibliotece graficznej.
I nie żebym miał cokolwiek przeciwko tradycyjnemu C - sam piszę kod do
większości swoich projektów w ten sposób. Jednak mamy XXI wiek, w MCU nie
trzeba już liczyć bajtów i cykli, a dzieciakom dzisiaj zaczynającym zabawę
z programowaniem w przyszłości prędzej przyda się umiejętność sprawnego
pisania obiektowego kodu.

Podpisuję się pod wszystkim Smile
Przy okazji polecam obejrzeć bardzo ciekawą prezentację pokazującą, że C++
może dać mniejszy kod niż C.
https://www.youtube.com/watch?v=PDSvjwJ2M80

--
Grzegorz Niemirowski
https://www.grzegorz.net/

heby
Guest

Tue Nov 16, 2021 6:18 pm   



On 16/11/2021 11:26, Grzegorz Niemirowski wrote:
Quote:
Zgadza się. Dlatego psu na budę debugger softwareowy w roli debuger
hardwareowego. To najzwyczajneij zupełnie inne zagadnienie.
Zgadza się. Ja tylko piszę, że debugger jest przydatny i wolę
środowisko, które go ma od środowiska, którego go nie ma.

Owszem, czasem się przydaje. Przydawał by się 100x bardziej, gdyby
zawierał symulator SoC. A tak, to tylko zabawka powodująca więcej
problemów niż rozwiązująca.

Tak czy inaczej, utracenie mozliwosci debugowania w małym programiku na
AtTiny, jest w zasadzie niczym cennym. Ot, gadżet, mało użyteczny w
praktyce.

Pcimol
Guest

Tue Nov 16, 2021 6:22 pm   



On 2021-11-14 17:46, heby wrote:
Quote:
On 13/11/2021 09:40, Bool wrote:
Dodam tylko że Arduino mnie kompletnie nie interesuje.

To jakiś pogląd religijny?

Nie, ale nazwa Arduino to taki fake.
Fajne powstają rozszerzenia harwarowe łatwo je obsłuzyć, ale nie
używałem nigdy narzędzi zapisujących ext .ino.
Może kwestia przyzwyczajenia.
A gdy ktoś mówi/pisze: "procesor Arduino", nie brzmi poważnie.

Pcimol
Guest

Tue Nov 16, 2021 6:30 pm   



To prawda, jednak w 20MHz ATMega (czy 32MHz XMega) trochę niekorzystnie
wypada overhead zasobów. To są sterowniki do najprostszych zadań. Prosta
maszynę stanów łatwiej napisać w C (włącznie z nauką tegoż pisania).

Atlantis
Guest

Tue Nov 16, 2021 7:30 pm   



On 16.11.2021 18:30, Pcimol wrote:

Quote:
To prawda, jednak w 20MHz ATMega (czy 32MHz XMega) trochę niekorzystnie
wypada overhead zasobów. To są sterowniki do najprostszych zadań. Prosta
maszynę stanów łatwiej napisać w C (włącznie z nauką tegoż pisania).

To oczywiste, przy czym dzisiaj coraz rzadziej zaczynając nowy projekt
sięga się po ośmiobitowe MCU (pomijając obecne problemy na rynku
półprzewodników) dużo łatwiej kupić jakiś układ STM32, który w tej samej
cenie zaoferuje co najmniej dziesięć razy tyle pamięci, szybsze
taktowanie i bogatszy zestaw peryferiów. W takiej sytuacji dodatkowy
narzut wynikający z użycia C++ nie jest wielkim problemem.

I jasne - kod pod MCU pisze się inaczej, bo cały czas trzeba uważać ze
stosowaniem kontenerów i algorytmów z STD, które dość intensywnie
korzystają z dynamicznej alokacji pamięci, jednak sama przejrzystość
obiektowego kodu jest sporą zaletą.

No i poza tym gdy ktoś już porządnie opanuje C++, to potem zrozumienie
"czystego C" przychodzi raczej łatwo.

Grzegorz Niemirowski
Guest

Wed Nov 17, 2021 10:53 am   



Pcimol <a_at_b.com> napisał(a):
Quote:
A gdy ktoś mówi/pisze: "procesor Arduino", nie brzmi poważnie.

Niektórzy używają nazw Arduino i AVR zamiennie.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

Marek
Guest

Wed Nov 17, 2021 11:45 am   



On Mon, 15 Nov 2021 20:22:11 +0100, heby <heby_at_poczta.onet.pl> wrote:
Quote:
sobie na jeden komplement: mimo wymachiwania pięściami przez
60latków z
embedded, wprowadził tylnymi drzwiami C++ do świata uC.
Podziękowania
się należą, nowe pokolenie programistów embedded będzie dzieki temu
bardziej ateistyczne.

Szczerze mówiąc nie wiem co chciałeś powyższym przekazać. Moje
doświadczenia z udostępnienia Arduino (i C++) znajomej osobie 60+
(prawie 70) jest takie, że kod jaki ona pisze to nie ma nic wspólnego
C++ a wygląda jak rzutowanie Pascala na C.

--
Marek

Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next

elektroda NewsGroups Forum Index - Elektronika Polska - AVR po latach

NOWY TEMAT

Regulamin - Zasady uzytkowania Polityka prywatnosci Kontakt RTV map News map