ARM

W dniu 2014-06-13 18:05, Sylwester Łazar pisze:

I to wszystko będziesz pisał w asm?

Z ARMów to chyba by trzeba coś z Cortex M4. Ja poza NXP za bardzo nie wiem, a w tych to nie ma wyboru. W serii LPC4000 jest kilka w obudowach LQFP100 ale chodzą na 120 MHz. Seria LPC4300 chodzi na 200 MHz ale najmniejsze obudowy to LQFP144. Jakoś ciężko znaleźć szybki procek z dużą pamięcią z małą ilością pinów. Pod tym względem może lepiej jest w STM - STM32F4, czy Stellaris.

To trochę zależy od tego jaki procek weźmiesz. Można zbudować sobie uniwersalnego toolchaina z Eclipse korzystając z porad Freddiego Chopina. Ale można kupić tani starter kit z programatorem i ze strony producenta pobrać środowisko. Ale to wszystko jest raczej na c.

No właśnie zależy od tego jaki procek wybierzesz.

Niektóre procki można programować przez prostszy interfejs - SWD. Niektóre programatory - jak np z zestawu LPCXpress mają na pokładzie oba JTAG i SWD.

W takiej sytuacji chyba najlepiej będzie wziąć jakiegoś ST na Cortex-M4F, evalboardy tanie, wybór duży, oprogramowanie jest, w sieci masa przykładów.

Nie tym razem. Poza wstawkami.

To chyba dobry pomysł. Kolega Jakub też tak doradza. No i ja dzisiaj na nie zerknąłem. Dzięki. S.

W dniu piątek, 13 czerwca 2014 18:05:12 UTC+2 użytkownik Sylwester Łazar napisał:

Dowolny jaki lubisz. ST jest bardzo popularne i sprzedaja/rozdaja tanie moduly ewaluacyjne.

Uzyj jakiegos RTOSa a toolchain bedzie Ci dany. RTOS moze okazac sie calkiem przydatny gdy dojdziesz do etapu system plikow FAT czy polaczenie po TCP/IP. Co do RTOSow to, np. :

- ChibiOs

- eCos

- Nuttx

- FreeRTOS itd.

Kupujac zestawy ewaluacyjne typu Discovery od ST "dostaniesz" programator przez USB. Podobnie rzecz sie ma w przypadku Freescale, NXP itd.

Wobec tego bierz od razu coś pokroju RaspberryPi.

99% kodu zostało napisane przez innych. Pozostanie napisanie skryptu w bashu w godzinkę. Suprise.

Innymi słowy chciałbym usłyszeć *dobry* powód dla którego komputer za

100zł jest gorszy niż procesor za 100zł + kilka godzin na lutowanie i kilkadziesiąt godzin na pisanie kodu i kilkaset godzin na klniecie czemu nie działa. Jesli takiego powodu nie ma - bierz Pi.

W dniu 2014-06-13 20:36, snipped-for-privacy@gmail.com pisze:

No i jest jeszcze CooCox. Podobno niezły.

Ludzie, którzy nie wykorzystywali Basha raczej nie rozumieją jego potęgi i tego jak szybko można mieć działające rozwiązanie, poprzez poskładanie tego co inni już dawno napisali i przetestowali.

jp

Sylwester już raz użył. Podobno z nie najgorszym skutkiem. Teraz tez go przekonam.

Głównym powodem jest to, że Pi jest gotowym modułem, który wprawdzie można sobie rozbudowywać o różne rozszerzenia, ale niekoniecznie nadaje się do tego żeby go po prostu montować we własne komercyjne urządzenie. Nie jest wprawdzie powiedziane, że ten projekt Sylwestra ma być wdrażany np. komercyjnie, ale przecież on zajmuje się zawodowo mikrokontrolerami. Tak więc ten projekt może traktować jako pewne rozszerzenie swoich kompetencji. Po co więc robić to na platformie, która raczej nie będzie przez niego zawodowo wykorzystywana. Być może i tak czuje potrzebę sprawdzenia czy współczesne ARMy i powszechnie stosowane środowiska nie są rozwiązaniem na które warto przejść. Pi moim zdaniem to jest platforma dla hobbystów umiejących pisać programy np pod Linuksa a nie chcących wchodzić w specyfikę pisania na mikrokontrolery.

Masz rację Sebastian! Bardzo Ci dziękuję za rady. W Twoim wydaniu są one zawsze bardzo cenne. Faktycznie wychodzi na to, że RP wpisuje się dość blisko w założenia. Jednak nie myślałem do tej pory o systemie operacyjnym. Muszę to przemyśleć. S.

Nie zgodze się. Bariera pomiedzy dolidnym uC a mizernym komputerem nie istnieje od wielu lat. Nie oznacza to że jestem zadowolony z faktu ze do migania diodą uzywa sie linuxa, ale z drugiej strony ide o zakład że nawet komercyjne urządzenie w kilkuset sztukach wyjdzie taniej z PI niż wydłubane ręcznie i wypoconym (i nie dzialającym przez 3 miesiące) software. Na moje oko Sylwester na problem rozwiązywalny Linuxem i do czasu aż nie usłyszę "przeciw" nie istnieje powód męczenia się z duzym uC tylko dlatego że to jest bardziej kanoniczne dla elektronika.

A przypominam że bez solidnego OS nie ma co się brać za uC z MMU, ethernetem i audio. Więc i tak jesteś skazany na gotowca. Więc lepiej wziąść gotowca 99% niż 20%. Dzisiaj na pisanie własnego OSa laski nie wyrwiesz.

Możesz bliżej, a raczej krócej, bo nie załapałem? S.

Dzisiaj uaktualniłem swoją wiedzę na temat ARMów i mam takie wnioski:

1) Faktycznie rozwój nastąpił dość duży, jeśli chodzi o wyposażenie "on board" 2) Zacząłem sobie czytać o tym STM32F429 i faktycznie lektura jest bardzo wciągająca.

Jednak zauważyłem, że producenci zdają sobię sprawę z możliwych problemów w opanowaniu tematu "ręcznie". Oferują najczęściej 2 rozwiązanie:

1) with OS 2) without OS (to chyba będzie składanie bibliotek) Ten drugi też reklamują, jako szybką drogę "time to market" I teraz pytanie: co wybrać? Czy bez systemu operacyjnego, ale z tymi ułatwieniami w postaci składania bibliotek to będzie te 20%? S.

Zalezy do czego. Nie wiadomo za wiele jaki masz problem. Jesli to problem z gatunku "przyszedł bajt na TCP/IP, zagraj plik foobar.mp3" to rozwiązanie masz w 15 minut na PI i w tydzień na "czymś", przy czym zakładam że pi nie znasz, a "coś" znasz nieźle.

IMHO nie ma o co walczyć z bibliotekami, bo są nie dość że kiepskiej jakości to czesto wymagają jakiś absurdalnych kompilatorów. Weź cokolwiek z linuxem i podobne do pi, wybór jest ogromny. Acz czy znajdziesz coś taniej nie wiem. Ja bym zrobił na złomowanym routerze za

10zł jeśli w jednej sztuce :)

W dniu 2014-06-13 19:20, Sylwester Łazar pisze:

z tego co koledzy z drugiej strony biurka się żalą, to Stellarisy to jakieś zło sprzętowe... prawie jak nvidia, gdzie połowa kodu to workaroundy hardwarowych błędów :)

@

W dniu 2014-06-13 22:58, Sylwester Łazar pisze:

Zastosowanie Pi wymusza na tobie rozwiązanie mechaniczne, które może ci z innych względów nie odpowiadać. Ja akurat robię kasety 2U z wsuwanymi kartami. Nijak mi Pi tu nie pasuje. Nawet jeśli można by go zmieścić na płytce to masz kanapkę która pod względem EMC będzie trudna do opanowania. Jak ktoś sobie chce odczytywać temperaturę czujnikiem na I2C to może nie ma to znaczenia. Natomiast przy czytaniu szybkiego przetwornika albo przy szybkiej komunikacji z FPGA to będą problemy. Poza tym jesteś skazany na gotowy moduł. Gdy im coś się odmieni za dwa trzy lata to jesteś w czarnej dupie. Nie ma czym ich zastąpić. Sam takiego modułu nie zrobisz bo nie kupisz procka. Poza tym, nie masz do niego dokumentacji tylko dostarczają API do obsługi GPIO. Jeśli już miałbym wykorzystać gotowe moduły to wybrałbym platformę microDAC.

ż masz na tym linuksa, a w dodatku wydaje mi się, że znacznie lepiej udokumentowany procek arm i DSP.

W dniu 2014-06-13 22:46, Sylwester Łazar pisze:

Napisałem obok w odpowiedzi Sebastianowi. Może nie krócej ale trochę inaczej :)

Da się zastapić *czymkolwiek* co obsługuje Linuxa. Czyli prawie wszystkim.

Właśnie użycie jakieś konkretnego procesora i wymordowane rękodzieło softu konczy się tym że producent wypina dupę albo podnosi cenę kilka razy. Kiedyś tak skonczyłem z SAM7S kiedy ceny skoczyły około 5 razy i

64k był droższy od 256k. To ja dziekuję za takie numery, atmel jest u mnie przekreślony w duzych cpu (z resztą support od strony programowania ział fuszerką).

Dlatego, jeśli okaże się że to projekt trywialny, należy uciekac od hardware a skupić się na software. Linux gwarantuje trywialne zastepowanie hardware.

PS. Nie każdy steruje hiper szybkim FPGA. Niektórzy grają tylko komunikaty zapowiadające pociąg...