Czy ktoś używa SourceBusterIDE , ś

Andrzej Kmicic pisze:

Daj sobie spokój. Na początek zaopatrz się w:

- MPLAB IDE - do ściągnięcia;

- debugger Microchipa ICD2 lub lepiej ICD3;

- kompilator microchipa MPLAB C for PIC18, wersja studencka bez ograniczeń na rozmiar kodu - do ściągnięcia;

Zapłacisz tylko za debugger. Reszta jest darmowa. Płyt ewaluacyjnych znajdziesz mnóstwo na stronie microchipa.

pozdr MŁ

Mariusz Ł pisze:

Qrcze, tyle lat jest PIC na rynku i nikt nie przeniósł gcc na tą platformę?

BTW: Jak miło, że taki np. Atmel daje darmowe środowisko AVR Studio, istnieje kompilator gcc a debugować można m.in. przez JTAG (klon JTAGICE kosztuje ze 100 zł). Jeszcze milej jest w ARMach bo tam to już wszystko za friko (programator/debugger JTAG na LPT Wiggler to części za kilka[naście] zł).

Mariusz Ł pisze:

Właśnie przymierzam sie do PICów. Jak dokładnie jest z tym kompilatorem Microchipa w wersji darmowej? Z tego co się zorientowałem to są jakieś ograniczenia co do optymalizacji kodu. Czy jeszcze jakieś inne?

pozdrawiam Elektrolot

Adam Dybkowski pisze:

Czy Microchip pobiera jakieś opłaty za środowisko ? Nie słyszałem. Debugger na LPT dzisiaj ? Sorry, ale to jakieś nieporozumienie. Jest jeszcze PIC32 starter kit z debuggerem USB na pokładzie za 36 euro. Kompilator C jest. Bazuje na gcc...

Elektrolot pisze:

Te optymalizacje możesz sobie darować na dzień dobry. Po prostu je wyłącz. Może (choć nie musi) wydłużyć to kod do 25%. Najważniejsze jest to, że nie ma ograniczeń na długość kodu. Kompilator ma bardzo dobrą dokumentację i to jest jego duży plus. Jeśli chodzi o zastosowania komercyjne, tu musisz poczytać licencję tej darmowej instalacji.

Pozdr, MŁ

Mariusz Ł pisze:

Ale tylko dla procesorów od pic24 w górę. Starsze wersje to ich własne wynalazki.

Mariusz Ł pisze:

Dzięki, juz mam dwa, sprawię sobie też debuger. Na pierwszy rzut oka na oba niczego konkretnego nie mogę powiedzieć ale mniej znane IDE SourceBuster wyglada zachecajaco. Jak zacznę działać, coś skompiluje to porównam i napiszę. Muszę kupic PICKIT3 i zacząć :-).

Dlaczego wybrałem PICe bo z wszystkich innych popularnych rozwiązań dla mikrokontrolerów chyba najlepiej maja rozwiązaną sprawę komunikacji ethernet a na tym mi zalezy najbardziej.

Interesuje mnie tez czy ktoś próbował komunikacji na poziomie sprzetowym ( tzn bez uzycia stosu TCP/IP). Chodzi o proste potwierdzenie PING lub ARP. Nie moge sie tego doszukać w internecie w wykorzystaniu PIC->ENC28J60.

Bo chyba jest to mozliwe, choć uzycie stosu teraz nie problem przy pojemnosciach flasha mc.

pozdr Ak

pozdr Ak

Andrzej Kmicic pisze:

:-o A właściwie czego wymagasz od komunikacji przez Ethernet w tym rozwiązaniu? Bo taki np. atmelowy AT91SAM7X też ma Ethernet, a gotowe systemy ze stosem TCP/IP (całkiem darmowe, nie Atmel proprietary) pozwalają od razu zabrać się za konkretną komunikację: patrz na m.in. Free RTOS, Nut/OS.

I co chcesz osiągnąć przez same PINGi? Ja pisałem w pracy magisterskiej własną obsługę protokołów ARP, ICMP, IP, UDP i DHCP:

No ale jeżeli bardzo chcesz, zrób na początek ARP. Wystarczy do prostych PINGów w ramach tej samej podsieci (komendą arping).

Andrzej Kmicic pisze:

Daj sobie spokój z SourceBoost. Ten kompilator swego czasu nie obsługiwał typu float. Nie wiem jak jest teraz. Jak interesuje Cię komunikacja ethernet, to zacznij od PIC32. Nie kupuj PCkita tylko starter kit PIC32 i do niego modulik ethernet. PIC18 są ciut za małe. Jak się rozpędzisz, to Ci zabraknie RAM'u...

Pozdrawiam, MŁ

Mariusz Ł pisze:

acha, moduliku ethernet nie musisz, bo jest wersja tego kitu PIC32 z ethernetem. MŁ

Adam Dybkowski pisze:

Dzięki, zajrzę. Sam ping a nawet arpping wystarczy aby zrobic prosty watchdog do switcha. Nie ma kilku odpowiedzi -> reset switcha. W rozwiązaniu tym chodzi równiez o niskie koszty.

pozdr AK

Mariusz Ł pisze:

Ok zajrzę i z pewnoscią sie zainteresuję ale jak pisałem wczesniej na poczatek i potrzeby rozgladam sie za prostym pingiem lub arpingiem z odbiorem odpowiedzi. Najlepiej Najprostsza aplikacja na warstwie sprzetowej, jezeli oczywiscie sie to uda. pozdr Ak

Andrzej Kmicic pisze:

A masz coś już w ogóle to tej "warstwy sprzętowej"? Jeżeli z jakiegoś przykładowego kodu (czy nawet większego systemu operacyjnego) wyciągniesz prostą funkcję wysyłającą ramkę Ethernet i podobną do odbierania - napisane obsługi ARPa jest już bardzo proste. Szczególnie jeżeli piszesz w C, a nie dziubiesz w asemblerze.

Adam Dybkowski pisze:

Czytałem Twoją pracę, to dobre wprowadzenie w temat komunikacji ethernet. Gratuluję.

Tak własnie myslalem napisać prosta obsługę ARPa na bazie niewielki PIC (myslałem bo kilka sztuk mam o PIC16F688 i ENC28J60). Na SPI i wyjscie wykonawcze powinno to wystarczyc. Kiedys pisałem i zadziałało w PHP "ręczne" składanie i wysyłanie ramki pinga wiec mysle ze moze i to wypali.

Jak złoze cos konkretnego dam znać lub poprosze o wskazówki :-).

Tak na gorąco zapytam pewnie szkolne pytanie ale w tym temacie jeszcze nie działalem praktycznie. Czy wiesz czy bufor w kościach ethernetowych takich jak ENC28J60 zapełnia sie tylko wówczas jezeli adres mac zgadza się z tym ustawionym dla kości ? czy tez bierze wszystko jak leci i programem trzeba odsiewać ?. Sądzę ze chyba to pierwsze bo w przeciwnym razie tam mógłby byc niezły kiszmasz :-).

pozdr AK

Andrzej Kmicic pisze:

Tego scalaka nie znam. Ale prawie zawsze (CS8900A, Realtek, LANC111) da się ustawić filtrowanie po adresie MAC (lub grupie multicastowej) i będą wtedy odbierane tylko ramki broadcastowe oraz dla tego wybranego adresu MAC. Alternatywnie można wybrać tryb promiscious, w którym scalak odbiera wszystko jak leci.