Mikropascal na AVR'y - co o tym sądzicie ??

Wziac lusterko, na lusterku narysowac ladne, duze "C" i wypic z tym "C" flaszke do lustra. Nastepnego dnia po kacu zostanie juz tylko kumpel c ;-)

Serio - nie da sie odejsc od C. Pascal/delphi jedzie w dol po rowni pochylej (ostatnie zrodla w pascalu widzialem przed rokiem 2000), a C bylo, jest i bedzie.

PS: C nie ma klonow. Owszem sa rozne standardy, ale IMHO dla Ciebie one sie niczym nie beda roznic.

MH snipped-for-privacy@gazeta.pl napisał(a):

Skąd się bierze ta irytacja i czy nie pora skończyć z takimi fochami? Po co na siłę szukać Pascala, skoro standardem jest C i jest do niego mnóstwo narzędzi, książek i przykładów w necie?

Kolega chyba dobrze podpowiedział. A co zamierzasz zrobić? Zobacz na przykłady, które są dostępne dla Twojego projektu. Jeśli są w Pascalu - weź Pascal, jeżeli w C - weź assembler :-) Wszystko zależy od tego ile masz czasu. Teraz czasu to nikt nie ma, więc najprościej wykonać 2 punkty z poradnika biznesmena:

1) wyłącz internet 2) weź się do pracy :-) S.

W dniu 2012-01-08 16:45 MH napisał(a):

Nie polecam.

Możesz przecież wziąć C ale dodać swoje makra preprocesora aby pisało Ci się "wygodniej" prawie jak w Pascalu. Na przykład:

#define begin { #define end } i całą masę innych, które wg Ciebie upodobnią C do Pascala. Z czasem z nich zrezygnujesz a znajomość C pozostanie.

Pascal i C to jezyki o praktycznie identyczym targecie, składni, możliwościach, koncepcjach. Tylko może poza tym że ostatni ludzie piszący w Pascalu wymarli 10 lat temu. Naprawdę spodziewasz się że ktoś tego trupa będzie reanimował bo jest 1 osoba na świecie chcąca w tym pisać na AVR? Dzisiaj jest tak że niepełnosprytni używają BASCOMa a pełnosprytni C/C++. Czas iść za stadem zamiast zajmować się archeologią.

Zmień na C. A jeszcze lepiej na C++, choć doskonale wiem że to nie będzie miało miejsca...

Należy polubić C. Jest to najbarciej naturalny język programowania.

Bez żartów - składnia C(+(+)) jest porąbana.

Jeszcze żyję! Co prawda ostatnio w Pascalu jakies 20 lat temu ale jakbym się uparł...

[...]

A ja na stare lata zaczynam mieć powoli chęć na pobawienie sie jakimis kontrolerami w C/C++ właśnie. Tylko nie wiem, od czego zacząć a wstydzę się zapytać :(

Jest identyczna z Pascalem z dokładnością do dupereli. Mogę te duperele zdefiniować, ale naprawdę Pascal i C stoją na jednej półce. Żeby zilustrować o czym mówię porównaj np C z Lispem (imperatywny vs funkcyjny). Natomiast porąbaność bezwzględna C[++] to kwestia gustu. Zawsze na pocieszenie możesz zobaczyć COBOLa. Jeśli chcesz zobaczyć np. hybrydę C z Pascalem z której wyszła katastrofa to możesz zobaczyc SystemVerilog. Naprawdę, jest masa języków znacznie gorszych od C[++].

*Nikt* poza szumem nie pisze w Pascalu nowych projektów. Delphi się jeszcze kreci bo są miliony lini kodu które trzeba utrzymać. Jednak środowisko programistów wymiera lub po cichu uczy się C#/Java doskonale sobie zdając sprawę że to trup. Pascal@uC to prędzej efekt 5 wieczorów nudzenia się. Ktoś chetny na projekt bez celu?

AVR a potem ARM. Bo dostępne, bo tanie, bo jest gcc, bo jest C++, bo jest support "google".

Kiedy własnie dostaję czkawki od tych dupereli. Przede wszystkim od zabawy operatorami :(

Ależ widziałem. I COBOLa i Algola. Ja stary jestem ;)

Przez prawie 20 lat żyłem z języka wysokiego poziomu, o rozbudowanej składni i raczej obawiam się, że będzie mi tego brakować. Z drugiej strony - do zrbienia migajacej diodki orłem w C nie trzeba byc ;)

Ale Delphi to też Pascal...

[...]

To tak, jakbys mnie namawiał do Linuksa, bo jest w nim "man". A to mi własnie Linuksa skutecznie obrzydziło lat temu sporo - w każdym razie za czasów wczesnego Slackware.

Problem w tym, że ja potrzebuję podpowiedzi na jeszcze niższym poziomie - czyli od jakiegoś zestawu startowego - programator, płytka uruchomieniowa, i komlet softu, który umożliwi mi uruchomienie migającej diody bez wielomiesięcznego kopania w Sieci. Już wiem, że programatory mają jakiś swój standard i warto kupić taki, który tego się trzyma.

W dniu 2012-01-08 23:44, RoMan Mandziejewicz pisze:

Jak cię męczy i++ to pisz i=i+1 :) Natomiast operatory przesunięcia, jak: #define ADC_DOUT_BIT ( 1 << 17 )

Ale to nie na tym polega, żeby sobie zmieniać język definicjami. Własnie zbyt duża łatwość zabawy definicjami, operatorami, przeciążanie operatorów zaciemniają programy i ciężko uczyć się na przykładach.

Nikt nie wymusza zabaw z nimi. Nie chcesz - zlewaj. Operatory to nie tylko zabawa - zobacz boost.org (w kontekście uC rownież).

Tak. To wypudrowany trup. W dodatku puder marnej jakości, generyki po 20 latach od reszty świata itp. Delphi się trzyma tak samo jak COBOL. Bo nie da się nagle wyciągnąć wtyczki. Ale zaraz sama wypadnie.

Gwarantuje Ci że na zajeciach ze studentami migającą diodę miałem po 20 minutach dysponując kilkoma drutami, płytka uniwersalna i kablem z LPT oraz AVRem w DIP w miedzyczasie instalując środowisko na Linuxie. Kilku zaszczepiłem bakcyla.

Płytka - w zupełności wystarczy uniwersalna stykowa.

Programator - byleco z allegro.

Komplet softu - WinAVR i Yagarto (ARM). Soft do programowania załączony.

Migająca dioda - exampl do napisania w 2 minuty bez żadnych makefile.

AVR - ISP, ARM - JTAG. Narzedzia darmowe. Programatory tanie.

W dniu 12-01-08 23:44, RoMan Mandziejewicz pisze:

Nie mam pojęcia czy przypadkiem nie przesadzam z "mierzeniem nisko", biorąc pod uwagę Twoje wieloletnie doświadczenie elektroniczne, tyle, że w zupełnie innej "szufladzie", ale tak jak koledzy napisali:

- jakiś breadboard, zrobisz sobie przecież na tym taką "płytkę uruchomieniową" jakiej będziesz na danym etapie potrzebował, częstotliwości ośmiobitowców nie są przecież tak wielkie, żeby pojemności i rezystancja "wciskanych" styków robiły jakiś problem w cyfrówce

- dowolny klon usbASP (albo samemu złożyć coś na LPT, jeżeli jeszcze posiadasz w komputerze)

- co do "migania diodą" to p. Górecki(?) z EdW(?) ZTCP napisał całkiem niezły kurs C/Cpp dla AVRów, tyle, że to było zupełnie "od zera", ale chyba przypomnieć sobie nie zaszkodzi.

- no a potem to już albo ścieżka "datasheetów", "application notes", albo gotowców z Google'a - ten punkt chyba zbyt wiele od "przetwornicowej analogówki" się nie różni.

[...]

Tak, jak pisałem wcześniej - Pascal to vyło ponad 20 lat temu - jakis wczesny TurboPascal. No i wczesniej na Spectrum - tam to była sama przyjemność ;) Ale w tamtych czasach wszystko było przyjemnością ;D

Hmmm...

Spamowany tu Multitool może być?

Zadziala z powyższym? W aukcji jest mowa o AVRStudio, Ty proponujesz WinAVR...

:)

A ro STK500?

To właśnie nęci. Bo wielu klientów koniecznie chce wciskać uC wszędzie a mi jest trudno odpowiadać na pewne pytania, nie znając mozliwości.

Arduino. Masz dużo gotowych dodatków, w sieci jest bardzo dużo materiałów, powstało sporo wersji rozszerzonych czy specjalizowanych do określonych zastosowań. Jeśli nie odpowiada Ci C/C++, możesz korzystać z arduinowego środowiska programistycznego i pisać w wiring. Radzą sobie z tym tysiące komputerowych analfabetów, więc dla Ciebie opanowanie programowania nie powinno być żadnym wyzwaniem. Migać diodką będziesz w max. 5 minut od wyjęcia płytki z pudełka.

j.

[...]

Jasne. Ale przydałby się jakiś link....

Myslę, że programowanie jest prostsze. Problem jest w samych początkach i "oczywistych" kruczkach.

Jak wypadnie Delhi, assembler, C, to kod pisany w Javie pojawi się na LCD po

500ms od naciśnięcia OK, na procku 1GHz. Nie ma na to norm. Elektryk - ma narzucone normy na prąd, przekrój przewodu, czas wyłączenia. Mechanik - ma narzucone normy na wytrzymałość materiału, średnicę drutu zbrojeniowego, klasę betonu Informatyk - wybiera Javę, najszybszy procesor, największą pamięć - nie ma norm na maksymalny czas obsługi zadania. Co 10 lat czas reakcji na naciśnięcie klawisza- podwaja się. Jest już masa symboli związanych z czekaniem: DOSowski progress bar, jeszcze taki w trybie znakowym, klepsydra, Timer!!!, wkurzające kółko, czy kulki latające na ekranie, jak łapa Kaszpirowskiego przed twarzą naiwnego itp. itd. Nie ma co - postęp. I to tylko w imię wygody. Nie namawiam do Pascala, ale tylko dlatego, że się nie przyjął. Basic się przyjął i był idealny do większości zastosowań. C upraszczał wiele z assemblera assembler bezkonkurencyjny czasowo. Delphi - szybki. Im starsza wersja tym szybsza. Java - ciągłe updaty. Na tej działa, na innej nie. Nie zaleca się tej, Telefony, które obsługuje w tym roku to:...itp. C++ coś czuję, że jest jeszcze strawny, ale brak mi doświadczeń w tym temacie, więc się nie wypowiadam.

W dniu 2012-01-09 00:10, RoMan Mandziejewicz pisze:

Coś mi ucięło: Natomiast operatory przesunięcia, jak: #define ADC_DOUT_BIT ( 1<< 17 ) są jakby stworzone dla mikrokontrolerów

W przypadku programów na mikrokontrolery nie ma tego dużo. Zwłaszcza gdy opisze się w c a nie w c++, a większość kodu jest jednak w c. Dasz radę. Sam jestem takim samym dinozaurem wychowanym na Fortranie a na mikrokontrolery pisałem przez lata w asemblerze. Do przejścia na c zmusiła mnie konieczność odejścia od '51. Po krótkiej przygodzie z AVR przeszedłem na ARMy a do c ostatecznie przekonała mnie możliwość zastosowania RTOSa i gotowych bibliotek do USB i Eth.

Najbardziej podobał mi się czas ładowania systemu :-) Nigdy się to już nie powtórzyło. Potem, i do dziś się zastanawiam, dlaczego na wszystko trzeba czekać, choć procesory z 3,5MHz zwiększyły prędkość ~1000 krotnie. Dobranoc. Idę zobaczyć, co z moją żoną. Dziś coś pisała w Delphi i trochę się boję w tej sytuacji :-) S.