Mikropascal na AVR: Czy to dobre rozwiązanie dla elektroników unikających C?

Mon Jan 09, 2012 4:01 pm   

On 2012-01-08 23:24, Sebastian Biały wrote:
[.....]

bani. Jeśli mówimy o programowaniu uC to w C da się "szybo pi..ąć
szybkiego pacza" i to jest IMO główny powód dla którego C jest popularne
wśród ludzi piszących soft na uC. Co z kolei w połączeniu z brakiem
doświadczenia i bliską zeru wśród elektroników wiedzą na temat
prowadzenia projektów software-owych prowadzi do powstawania
programistycznych koszmarów. C daje dużą swobodę i dlatego IMO nie jest
to dobry język dla początkujących ponieważ trzeba wiedzieć co się robi.
Z drugiej strony działającej i powszechnie dostępnej alternatywy
wymuszającej dobre praktyki (np. Ada) na popularne uC za bardzo nie ma...

Poza tym AFAIR to informatycy (ci zajmujący się dydaktyką) twierdzą, że
Pascal *nadal* jest niezłym językiem do dydaktyki.

BTW. Trup na trupa: http://en.wikipedia.org/wiki/Turbo51 Ktoś chyba
podchwycił Twój pomysł.

Mon Jan 09, 2012 4:06 pm   

W dniu 2012-01-09 14:40, RoMan Mandziejewicz pisze:


odezwij sie na priv z adresem do wysyłki (w moim adresie jest gazeta.pl)

--
Pozdr.
Michał

Mon Jan 09, 2012 4:17 pm   

On 2012-01-09 02:04, RoMan Mandziejewicz wrote:
[.....]

problemów, zwłaszcza wtedy, gdy rozmiar kodu i/lub danych zacznie
ocierać się o granicę 64KiB. IMO w przypadku projektów które mają być
wdrożone w małej ilości egzemplarzy zupełnie nie ma co zawracać sobie
głowy ośmiobitowcami aby zoptymalizować koszty.

Mon Jan 09, 2012 4:33 pm   

On 2012-01-09 02:11, Jacek Radzikowski wrote:
[.....]

kilkoma/kiludziesięcioma KiB RAM w zasadzie tylko C, C++ i BASIC są
dostępne.

Mon Jan 09, 2012 4:53 pm   

On 01/09/2012 10:33 AM, JDX wrote:

Plus wymienione w wątku Wiring i Ada, jest python na mikrokontrolery,
NesC też jest bardzo przyjemne i wydajne, znajdzie się pewnie jeszcze
kilka innych języków. Jest w czym wybierać.

j.

Mon Jan 09, 2012 5:06 pm   

On 01/09/2012 04:49 AM, Waldemar Krzok wrote:

O ile MSP uważam za wspaniałą rodzinkę procesorów, to jednak bym uważał
z polecaniem Launchpada komuś kto dopiero zaczyna zabawę. A jeśli już to
razem z samplami MSP430G2553. O ile TI nie uaktualnił zestawu
dołączanych kostek, to procesory w zestawie mają bardzo ograniczone
możliwości sprzętowe.

pzdr.
j.

Mon Jan 09, 2012 5:20 pm   

Am 09.01.2012 17:06, schrieb Jacek Radzikowski:

Może i ograniczone, ale dostajesz je praktycznie za darmo. A parę rzeczy
można na tym zrobić. Mój miernik impedancji elektrod, na przykład,
chodzi też na kostkach z zestawu. Trochę akademicko sprawdzałem, bo już
mam gotową płytkę na F2013, ale się da. Albo proste międzymordzie do
klawiatury pojemnościowej. Program jest już gotowy, dorabiasz tylko
wyjście do reszty systemu i jazda. A te trochę większe procki serii G
można sobie zasamplować. W każdym razie polecam zainteresowanie się tym
procesorem, bo świetnie nadaje się do zastosowań bateryjnych. A
16-bitowe ADC w niektórych prockach serii F też piechty nie chodzi. OK,
wyciągnie się 14 bitów, ale te bez specjalnej gimnastyki i modłów do
wszystkich bogów.

Waldek


--
My jsme Borgové. Sklopte štíty a vzdejte se. Odpor je marný.

Mon Jan 09, 2012 5:33 pm   

On 01/09/2012 11:20 AM, Waldemar Krzok wrote:

Podpisuję się pod tym wszystkimi łapami. Ale tylko jeśli ktoś wie co
robi. IMHO brak sprzętowego UARTU dyskwalifikuje małe procesory z serii
G2 do zaczynania zabawy z mikrokontrolerami. Programowy uart może być za
trudny do opanowania, a poza tym zjada sporo zasobów. Na 2kB flasha też
się nie poszaleje. Dlatego też wspomniałem o samplach MSP430G2553. Ma
wszystkie peryferia niezbędne do rozpoczęcia zabawy i 16kB flasha.
Sensowną alternatywą dla launchpada i sampli jest zestaw Experimenter
Board dla nowej serii procesorów MSP z pamięcią FRAM zamiast flasha. Ale
kosztuje trochę drożej niż launchpad :(

pzdr.
j.

Mon Jan 09, 2012 5:46 pm   

Am 09.01.2012 16:01, schrieb JDX:

Pascal JEST językiem do dydaktyki. Ma jednak lekką niechęć do
programowania blisko hardware. Konkretnie w Pascalu tak jak bóg (znaczy
Wirth) go stworzył nie ma możliwości adresowania komórek pamięci (ok, da
się poprzez przypisanie stałej do wskaźnika, ale ładnie to nie wygląda),
a do przerwań czy, o zgrozo, multithreadingu wogóle nie ma ładnej
możliwości. Delphi jest pewnym krokiem od dydaktyki do produkcji, ale
ten koń też już zaczyna śmierdzieć.

Co do mikroprocesorów, to C jest kompromisem między assemblerem, a
"porządnym" językiem. Im mniejszy mikrokontroller, tym bardziej mamy
tylko te 2 języki jako alternatywy. A ładnie programować można w
dowolnym języku i na odwrót. Jak mamy większe kostki, to już zaczyna być
wygodniej, aż do składania programów z graficznych "kostek", jak to mają
co poniektóre PLC. Albo LEGO MasterMind (R). Tam sobie układasz klocki
LEGO na ekranie i toto nawet działa .

Osobiście znam trochę tych języków programowania. Programy popełniłem
chyba w 30 językach, większość jednak to dydaktyka na uczelni (też jako
nauczyciel). Poczynając od Fortranu, przez wsie Algole, Prolog, LISP (od
tego miałem rekurencyjne sny ), a nawet jakiś śmieszny programik w
Cobolu na zaliczenie. W tej chwili używam C lub C++ na PCcie, C lub
Assembler na mikroprocesory. No i ostatnio jakiś Arduino ze swoim
"prawie-C", albo procesor graficzny z 3GC, czy jak temu dialektowi. Jak
się umie programować, to język właściwie obojętny. Ale to chyba tak, jak
z językami obcymi: tych 0x10 pierwszych sprawia problemy, następne
wchodzą jak przez masło .
Warto wiedzieć, że im bardziej abstrakcyjny (i wymuszający dobre
praktyki) język, tym trudniej jest optymalizować kod. Pisząc program
zajmujący mało pamięci i szybki musi się myśleć kategoriami procesora.
Trzeba wiedzieć gdzie są tworzone zmienne, unikać konwersji między
różnymi strukturami danych, conieco pozostawić w rejestrze. Przy
przerwaniach ratować tylko te rejestry, na których operujemy i podobne
cuda. Już w C coponiektórzy wywalili się na prostym printf. Program miał
powiedzmy 1k, dodano jedną linijkę z printf i już ma 20k, albo i więcej.
Bo się całą bibliotekę zmiennoprzecinową dolinkowało, choć tego nie trzeba.

Waldek


--
My jsme Borgové. Sklopte štíty a vzdejte se. Odpor je marný.

Mon Jan 09, 2012 5:49 pm   

On 2012-01-09 16:53, Jacek Radzikowski wrote:
[.....]

dobrego taniego bądź darmowego kompilatora. A przynajmniej ja takowego
nie znam. Zresztą Green Hills nie oferuje narzędzi na "drobnicę" typu
AVR, H8 czy MSP430. Natomiast AVR-GCC jest AFAIK od kilku ładnych lat w
powijakach. Swoją drogą swego czasu nawet sam myślałem aby zrobić coś
takiego dla H8/300H i H8S.

Python? Ale to chyba masz na myśli (typowe) używanie go jako embedded
command interpreter a nie jako kompilowany język masowego rażenia do
którego wkładasz źródła a wyjmujesz binarkę do wypalenia w jakimś
ROM-ie. Zresztą Python ze względu na dynamiczność typów i automatyczne
zarządzanie pamięcią IMO raczej słabo nadaje się do tworzenia
oprogramowania systemowego. Chociaż jako język osadzony rzeczywiście
jest w porządku.

Wiring? O tym mówisz
http://en.wikipedia.org/wiki/Wiring_%28development_platform%29? Nie
znam, ale wygląda na to, że używanymi tam językami są C i C++. Poza
tym Wiring nie jest językiem programowania. :-)

NesC? O to chodzi http://nescc.sourceforge.net/? Nie znam, ale wygląda
na jakiś mocno specjalizowany język. Bazowany na C. :-)

IMO jeśli się przyjrzysz to za bardzo nie ma w czym wybierać. Bo albo
brakuje kompilatorów (wspomniana Ada) albo sam język programowania
niejako z definicji niezbyt pasuje do (takiego prawdziwego
niskopoziomowego) embedded software developement (wspomniany Python czy
tez mój ulubiony Eiffel).

Mon Jan 09, 2012 6:03 pm   

On 9 Sty, 12:04, RoMan Mandziejewicz <ro...@pik-net.pl> wrote:

Nie poddawaj się :]

Ja też zaczynałem otumaniony bo za dużo tego na raz, w końcu kupiłem
sobie

http://www.btc.pl/?id_prod=38700

razem z zestawem uruchomieniowym i programatorem. Wiadomo że płytkę
można sobie samemu, ebooka w pdf się ściągnie itp. ale tutaj masz
wszystko podane na tacy, zestaw jest akurat dla średnio kumatego
elektronika który chce sobie pomrugać diodami i ponaciskać guziki.

Pzdr.
L.

Mon Jan 09, 2012 6:20 pm   

RoMan Mandziejewicz <roman@pik-net.pl> napisał(a):


jak w celach edukacyjnych zalaczyc przekaznik na 2 sekundy, prosty lcd + avr
to moze to
http://www.matrixmultimedia.com/lc_index.php?p=7
zawsze pozniej mozna tam wklepac cos w C jak i asm

Ja pisze z perspektywy amatora :)





--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

Mon Jan 09, 2012 8:48 pm   

Dnia Mon, 9 Jan 2012 01:04:42 +0100, RoMan Mandziejewicz napisał(a):


Prosisz - masz: http://sklep.avt.pl/p/pl/485505/kurs+c.html Nie wiem
nawet, czy PDFy z tym kursem (był publikowany od maja 2005) nie są
dostępne za darmo w archiwym EdW na Elportalu.

Tamten kurs jest naprawdę przystępnie napisany. Wyjaśnione są podstawowe
zagadnienia odnośnie instalacji i konfiguracji pakietu WinAVR+AVR
Studio, struktury plików makefile itp. sprawy. Jeśli zaś chodzi o sprzęt
do ćwiczeń to po kilku próbach z różnymi płytkami skończyłem na tym:
http://obrazki.elektroda.net/97_1326138021.jpg
Wzór PCB do tego masz tutaj:
http://elportal.pl/ftp_05/201008szkola169.zip (paczka 169hoffmann.zip w
środku). Proste i najlepsze - co będziesz potrzebował to sobie
podłączysz a w gruncie rzeczy złącza śrubowe dają najpewniejszy styk i
są najszybsze. Może też być jakaś płytka stykowa ale mi one nie leżą pod
AVRy ze względu na dwurzędowe złącze programatora - taki sobie przyjąłem
standard.
--
Pozdrawiam Bad Worm badworm[maupa]post{kropek}pl
GG#2400455 ICQ#320399066

Mon Jan 09, 2012 9:28 pm   

On 2012-01-09 01:43, RoMan Mandziejewicz wrote:

Nie nie pomyłka. Mikolaj już był, ale masz tutaj prezent:

http://sebobialy.net/avr.zip

W środku 3 pliki. Odpalasz compile.bat a potem odpalasz upload.bat i
masz migającą diodę na mega88. Programator to usbasp, ale możesz sobie
zmienić, chyba widać gdzie, tak samo jak procek. Prościej się chyba nie
da. Dla oswojenia compile.bat generuje jeszcze źródlo w asm do wglądu.


To nie jest prawda. makefile przyda się kiedy projekt będzie duży. Jesli
składa się z kilkunastu plików .c możesz je kompilować hurtem za każdym
razem i nawet nie poczujesz.


Wszystko w examplu. Pamiętaj tylko żeby WinAVR był na ścieżce i odpali.

Miłego migania.

Mon Jan 09, 2012 9:34 pm   

On 2012-01-09 16:01, JDX wrote:

Dłubanie po gołej pamięci odbywa się znacznie sprawniej w C niż w
Pascalu. Ludzie od uC lubią dłubać jak w asm. Z resztą wiekszość kodu na
uC wyglada jak asm. Pascal mocno to ogranicza. Zapewne z tego powodu
przyjął się też Verilog. VHDL jest zbyt restrykcyjny i gadatliwy, a
korzenie z Pascalem wspólne.


Albowiem? Przy czym zaznaczam że też byłem rzeczonym informatykiem
zajmującym się dydaktyką. Nie jestem w stanie, mimo najlepszych chęci,
znaleźć choćby pół powodu.