Mikrokontrolery, kierunki rozwoju, linux czyli "reaktywacja"

Question

Witam Po kilku latach przerwy z mikrokontrolerami postanowiłem wrócić "do branży" i trochę nadrobić stracony czas, aby znowu być na bieżaco w tym te...

nsvinc · Answer

STM32 to dobre procki. Ani nie są jakoś strasznie drogie, ani nie mają przerażającej erraty tak jak np. niektóre procki Microchipa czy NXP. Za to biblioteki do nich nie są

Jado_one wrote:
niedopracowane

tylko po prostu są do d**y. Ż tego co się orientuję praktycznie żaden dobry konstruktor pracujący z tymi prockami tej biblioteki nie używa, i namawia się początkujących, aby tego niewydajnego i pogmatwanego klotza nie dotykali...

Jakie procki bym polecał? Na pewno STM32 bez głupich bibliotek. Na pewno LPC11xx/LPC13xx, dobre sprawdzone i bajecznie tanie procki oparte o rdzeń CortexM0/M3
Można dotykać też PICów, w szczególności PIC32, ale ja kiedys pracująć z PICami na chwilę obecną się wycofałem (po trzecim zjaranym ICD3 i nieskonczoną listą ograniczeń i bugów w IDE), i wracał nie będę. PICe są dobre do SMPSów (bo nie ma dla nich zamiennika), i to są jedyne układy które obecnie robię w oparciu o dsPICki.

W ośmiobitowce chyba nie warto wchodzić ogólnie, ponieważ obecnie zaczynają być wypierane przez 32bitowe procki na rdzeniu CortexM0, i tylko jeszcze poczekać parę lat, a niedługo smutne 8bitowe architektury odejdą do lamusa, bo od armów CM0 nie będą one ani lepsze, ani tańsze, ani bardziej energooszczędne...
Chybaże mówimy o takich 8bitowcach jak PIC10F w sześciopinowych SOT23, które kosztują porównywalnie tyle, co popularny opamp czy TS555 ;] - dla takich procków zawsze znajdzie się "idealne zastosowanie"...

Mamy jeszcze MSP430 - 16bitowiec, który kiedyś słynął z tego że "nie pobiera prądu". Jak jest obecnie - nie wiem, bo nigdy tych procków nie dotykałem.

Jeśli masz zamiar zajmować się fascynującym power electronics, to tu muszę polecić tylko i wyłącznie 16bitowe dsPICe z serii GS. Na rynku nie ma procka który im dorówna w aplikacjach dowolnych przetwornic czy motor control - jedyna ich wada to ich nigdy niezaspokojony głód na energię ;]. Jeden przeciętnie eksploatowany (sterujący czteroma buck-ami w trybie prądowym przy 330kHz) dsPIC33FJ16GS502 wszamie spokojnie nieco ponad 100mA jeśli zapuści mu się peryferia DPWMa i ADC na maksymalnej prędkości (ponad 100MHz zegar!)

Co do IDE, nie wypowiadam się, bo zaraz dostanę lincz za promowanie profesjonalnych komercyjnych środowisk ;]
Ja pracuję w Keilu MDK-ARM pod głupim Windowsem XP64, i mi z tym dobrze... ;]

paw789 · Answer

LPC13xx ma rdzeń Cortex-M3Również uważam że AVR odejdą do lamusa, LPC11xx/LPC13xx prawie każdym względem są lepsze od AVR, ich jedyną wadę jak jedynie może być brak wersji w obudowie DIP która ułatwia start i prototypowanie... Uważam że przyszłość należy do Cortex'ów, z szerokim wachlarzem wyboru rdzenia do wielu zastosowań: M0 - M4, R4-R7, A5-A15, używanych przez wielu producentów uC. Aktualnie korzystam głównie z LPC17 z Cortex-M3 i uważam że to świetny uC w tej cenie. Warto zwrócić uwagę na ofertę mikrokontrolerów firmy TI, która ciągle się rozrasta, kilka dni temu wypuszczono nową serię ARM Hercules z rdzeniami Cortex-M3 i Cortex-R4F. Nie miałem okazji jeszcze korzystać z serii Concerto od TI (2 rdzenie: CortexM3 i DSP Delfino) który jest tym czego szukałem przez długi czas, pewnie będzie stosowany powszechniej niż szumnie zapowiadane LPC43xx (2 rdzenie: M4 i M0). Uważam że przyszłość należy do TI jeśli chodzi o ARMy i profesjonalne zastosowania.

nsvinc · Answer

Racyjka ;]

Jado_one · Answer

Dla uściślenia - mówimy o: STM32F10x Standard Peripherals Library?
Zeby było śmieszniej, to obie ksiązki o STM32 własnie na niej się opierają w swoich opisach
No, ale ksiązki jak to ksiązki - dobre są jako wprowadzenie do tematu, a po szczegóły zapraszamy do datasheetow, manuali, opisów w internecie

nsvinc · Answer

Dokładnie. Te książki nie opisują procesora, tylko bibliotekę do tego procesora - czyli de facto bezużyteczne. Ofiara tej biblioteki zostaje wciągnięta w otchłań otępienia i vendor lock-in'u, a później próba wyrwania się z nałogu jest trudna, wymaga wiele wysiłku i nauki praktycznie wszystkiego od początku...

Jado_one · Answer

No to pieknie....dobrze, że mam jeszcze "DefinitiveGuidetoCortex-M3", to sobie co potrzeba doczytam.....

Krisgorn · Answer

MSP430 to mikrokontrolery 16-bitowe.

nsvinc · Answer

Zawsze myslałem że 8bit ;D No cóż, nie znam się na niczym więcej niż na dsPICach i ARMach...

tymon_x · Answer

Zatwardziały windziarz (kilka latek), też przeszedł na Linux'a i to już definitywnie nie ma odwrotu, to jest jak narkotyk

Nie ma lepszej platformy do developing'u, hardware czy software.

1. IDE
Mam jedno środowisko, ale do wszystkiego. Jest to Eclipse Classic (obecnie Indigo) z masą pluginów. IDE strasznie intuicyjne i podatne na modyfikacje. Nic ci nie przeszkodzi, żeby zrobić np. symulator dla rdzeni ARM jaki ma np. Keil, a nawet lepszy. Wymaga tylko troszkę skill'a w Java i zapału. I za pomocą jednego środowiska możesz, przełączając tylko workspace i perspective (żeby nie robić Sobie śmietnika), ja osobiście mam tak:
-AVR, kompilator GCC-AVR, współpraca z AVRDUDE, graficzny konfigurator FUSE (nienawidzę tego wynalazku

).
-ARM, np. toolchain CodeSourcery, graficzne debugowanie rejestrów (EmbRegView), debug w współpraca np. z OpenOCD i z edytorem, piękna sprawa. Plugin do automatycznej generacji Makefile (leniwy jestem

)
-CDT, programowanie w C/C++.
-Java
-JNI + JAVA (czyli C/C++ w Java)
-VHDL/Verilog, sprawdzenie składni i symulacja
-Linux Embedded, symulator jądra, pisanie driver'ów staje się przyjemniejsze
-tworzenie własnych plugin'ów do Eclipse
-no i podłączanie własnych narzędzi, darmowy kompilator do DSP IT (seria C54, C55, C6x). tylko dostępny na Linux'a. GNU Toolchain dla Blackfin'a (DSP Analoga, tego nie ruszałem

). Własny toolchain pod Embedded Linux za pomocą Crosstool-NG, OMAP53xx, i.MX233 i i.MX53. Nie było żadnych problemów, builduje, kompiluje, śmiga

-masa pierdół, pluginów wspomagających pisanie aplikacji Embedded
-i wiele innych...

2. Programatory
Tu polecam Versaloon, Versaloon - DIY elektroda lub coś na FT2232 + OpenOCD. Obsługuje ARM, AVR, CPLD, FPGA i inne mniejsze. Mikroprocesorami z serii Cortex-Ax też sobie poradzi.

3. Embedded Linux
Z tym miganiem diodki na Linux Embedded też mam za Sobą i to nie będą żarty pewnie w przyszłości, nawet aplikacja w Qt-embedded pod to napisałem

Ale nie radzę na początek tworzyć całej platformy hardware na własne widzie-misie, najlepiej dostosować się do dostarczonego BSP od producent, a później pod jakimś level-upie porwać na u-boot'u, ng-tools, najnowsze jądro, własne driver'y i tak dalej na własną rękę.

4. Linux
:sm3: nic dodać nic ująć. Bez takich narzędzi jak vim, diff, grep, sed, nie da się sensownie tego ogarnąć, winda się zdecydowanie chowa

A kompilatory pracują jak malinka, miodzio... Dostęp do zasobów jest banalnie prosty, w myśl zasady że wszystko jest plikiem

5. Mikrokontrolery
Polecam tanie i nowoczesne uC z rdzeniem Cortex-Mx. Energy Micro ma w ofercie bardzo uC z serii lower-power. Do powszechnego użytku STM32, albo LPC1xxx. Małe i zgrabne aplikacje LPC11xx i pamiętaj do tego wystarczy jedno IDE i JTAG (ex. FT2232), wszystko za free. Z interfejsem SWD -> Versaloon.

6. Mikroprocesory
Z jakimi miałem styczność to i.MX (Freescale) oraz OMAP (TI). Ten pierwszy ma przyzwoicie zrobiony BSP, ale z błędami (definicja portów z BGA i.MX28 dla i.MX223, źle napisane obsługa karty SD z wieloma urządzeniemi na linii SPI, UART źle zdefiniowany, i wiele innych). Z OMAP, bardzo fajne mP, tylko denerwuje mnie ten bootloader

Też za free...

7. Narzędzia
-OpenOCD
-KiCAD, płytki wielowarstwowe, program bez ograniczeń
-do FPGA (Altera/Xilinx/Lattice z tym ostatnim są mega problemy pod Linux'em, 64-bitowym).

Ja z czystym sumieniem mogę polecić każdemu elektronikowi Linux'a, nie ma lepszego OS'a

Otwarte źródła, free, wolność, duże możliwości, czasem tylko można posunąć się za daleko

See also:
05.02.2017 uTest - framework C++ do testów jednostkowych dla urządzeń wbudowanych

nsvinc · Answer

Linuxa trzeba się uczyć i go znać. Pod linuxem nie chodzi Altium, z którego nie potrafię (i nie mogę) zrezygnować. Pod linuxem nie chodzi Embarcadero BDS. 3/4 softu który znam i używam do życiowej pracy niestety linuxa niet ;]

Miałem już okazję z linuxa korzystać, minąłem już różne dystrybucje od starego (naprawdę starego) Corela, przez różne Red-Hat, Mandrake, Mandriva, Ubuntu, liznąłem też FreeBSD i wiecznie jest ten sam problem - zamiast zająć się swoją pracą, musiałem zajmować się systemem.

Popatrzmy, co nie ruszy spod linuxa: TI FilterPro, TI SwitcherPro, SolidWorks, PiExpert, Altium, Alcohol 120%, Photoshop, Keil chyba też nie, i nawet mój ulubiony IM (czyli aqq) też nie. Dodatkowo: Linux + WiFi = bardzo średnio... Marnowałem tygodnie czasu na samo dostosowanie systemu do tego, zeby móc uruchomić z wykorzystaniem Wine durnego Keila :/

Napisałeś, że Versaloon obsługuje SWD, ale czy soft który obsługuje Versaloon, to nie jest przypadkiem openOCD, który SWD nie obsługuje, i jeszcze długo obsługiwać nie będzie?...

tymon_x wrote:
Nic ci nie przeszkodzi, żeby zrobić np. symulator dla rdzeni ARM jaki ma np. Keil, a nawet lepszy. Wymaga tylko troszkę skill'a w Java i zapału.

Symulator rdzenia to szczegół - rdzen tylko interpretuje rozkazy. Symulator gotowego procesora - o, to jest to; zaimplementować wirtualny jego memory-map, symulować SPI, ADC, DMA, NVIC, timery, oscylatory, PLLe, DAC, I2S...
Dziesiątki tysięcy kodu w Javie. A Javę trzeba lubić, żeby w niej pisać - ja nienawidzę. Właśnie Javie mogę zarzucić zmarnowane ponad 800MIPSów w moim smartfonie na przycinający się 2D GUI, zwiechy gdy procek rozmawia do peryferiów (mass storage, aparat, modem gsm, gps...). Więc jednak istnieje taki punkt widzenia (np. mój) który linuxowi (jak i Javie) mówi stanowcze NIE.

Anonymous · Answer

True. Też mam podobnie. Niestety są dwa kolce.
Aby dojść do takiego stanu trzeba być zawodowcem (wliczam też amatorów - zawodowców ;-)

)
A jak jesteś zawodowcem to nieraz specyfikacja zamówienia sprowadza Cię przez okno na ziemię ;-)

nsvinc wrote:
Linuxa trzeba się uczyć i go znać.

Tak samo jak i okien. Tu nie ma problemów.
Natomiast z programami faktycznie trzeba się przestawić i trochę brakuje.
Ale jak się przestawisz... . Dobra nie będę powtarzał po Tymonie ;-)

Albert

tymon_x · Answer

Dzięki temu, że źródła są otwarte, autor przygotował łatkę do OpenOCD. W dodatku sam robiłem poprawki do SVF Player'a. Takie uroki OpenSource, jak chcesz żeby działało, najlepiej zrób to sam A obsługa SWD przez OOCD ma być zaimplementowana, szefem projektu nad tą biblioteką jest Polak. Noo, miało też być symulator procesora, zagalopowałem się wstecz

nsvinc · Answer

Właśnie - ma być. Gdybym liczył na OOCD, to bym do dzisiaj nie pouruchamiał tego co miałem zrobić na LPC11xx, tylko byłby płacz i zgrzytanie zębami...Podyskutujmy ;] Nad projektami open source pracują przeróżni ludzie. Od amatorów po specjalistów. Jako że przeważnie jest tak, że w jednym projekcie grzebie masa różnych losowych ludzi, cały soft po kilkudziesięciu takich zmianach staje się jednym wielkim bajzlem, w który każdy programista wstrzyknął jakiś swój pomysł, niezawsze robiąc to bug free i nie zawsze odpowiednio testując - nie powiesz mi przecież, że wszyscy z definicji będą stosować TDD. I równie nie wszyscy będą stosować agile programming. Właśnie linux stał się takim bajzlem - tysiące ludzi podopisywało tysiące rzeczy w sposób tylko i wyłącznie sobie znany - weźmy np. taki IOCTL, który jest bardziej wszechmocny niż Bruce, czy Evan ;] I nie dziwię się - pomysł na kernel był, pomysł na system był, i wszystko to, co nie zostało przewidziane od razu, wrzucono w jedną magiczną funkcję ;] Nie raz mi zdarzyło się mieć w swoich softach to samo.Pytanie, czemu musiałeś go poprawiać? Jakby został napisany komercyjnie, to byłby tak przetestowany, że ty byś się tylko cieszył jego funkcjonalnością, i do głowy by ci nie przyszło, żeby coś poprawiać - po prostu by działało...Open source jest fajny - zgadza się. Ale nie tu, gdzie liczy się time to market, niezawodność czy stabilność. IMHO lepiej jest, jeśli nad konkretnym projektem pracuje konkretna grupa ludzi, którzy "ciągną razem w tą samą stronę", a nie każdy według swojego widzimisię...

Freddie Chopin · Answer

Symulator rdzenia jest realizowany przez gdb - wystarczy uruchomić go z parametrem "target sim" i chyba cośtam jeszcze, ale ogólnie to działa całkiem sprawnie. Oczywiście zastosowanie jest nikłe, bo nie ma symulacji rzeczywistych układów peryferyjnych. Tak czy siak moim zdaniem symulatory są przereklamowane - nie widzę specjalnego zastosowania dla nich kiedy ma się JTAGa. Symulator - jeśli będzie naprawdę dobry! - pomoże nam zdiagnozować problemy dotyczące tylko wewnętrznych układów peryferyjnych, a jak często problemem jest np. komunikacja z lub sterowanie innymi układami? Pozatym problemy z mikrokontrolerem znakomicie rozwiązuje trzymanie się tego co piszą w user manualu, a dopiero POTEM wywalanie rzeczy pozornie zbędnych (najlepszy przykład - I2C@STM32, w którym trzeba odczytywać rejestry statusu żeby flagi wyczyścić).

Mnie na Linuxie brakowałoby tylko Altium Designera tak naprawdę (; Całą resztę można zastąpić. To czego nie da się zastąpić instalujemy pod Windowsem postawionym na VirtualBoxie i problem z głowy. Ja niestety na razie mam odwrotnie, tzn mam Linuxa postawionego na VirtualBoxie, ale może kiedyś role się odwrócą?

4\/3!!

See also:
07.03.2015 [C++11][Cortex-M3/M4] - distortos - obiektowy RTOS dla mikrokontrolerów w C++
10.02.2013 bleeding-edge-toolchain - kolejny toolchain dla ARM

nsvinc · Answer

No więc właśnie ;] Ale symulator ma bardzo ważne zastosowanie, gdy stosuje się TDD. W projekcie na LPC1113 sam procesor był symulowany po to, aby w czasie rzeczywistym przeprowadzić jednostkowy test danej funkcjonalności. Śledzenie przebiegu testu przez SWD byłoby utrudnione ze względu na znacznie wolniejsze odświeżanie watch-y i memory view. Symulator równiez pomaga pisać kod na sucho - często jest tak, że mam pomysł na cośtam, więc siadam i piszę. Nie muszę w panice szukać fizycznego sprzętu i przejściówki SWD do niego ;] Potem testuję funkcjonalność na pałę w symulatorze, lub piszę test i śledzę w symulatorze jego przebieg... proste? ;]

Freddie Chopin · Answer

Wielu różnych układów nie da się debuggować i jakoś da się na nich robić skomplikowane projekty - już nie przesadzaj że brak możliwości debuggowania takiego prostego układu cokolwiek by Ci utrudnił.Mylisz się. W projektach OS poświęca się wiele czasu i energii na to, żeby kod był zrozumiały, poprawny, czytelny i bezbłędny. To nie jest tak, że każdy może sobie coś napisać i to od razu ląduje w oficjalnym repozytorium. W takim Linuxie czas akceptacji Twojej poprawki (zakładając, że faktycznie jest dobra!) wynosić może kilka tygodni, bo wielu ludzi musi to przejrzeć i zaakceptować. Jak rozumiem w komercyjnym oprogramowaniu "nie ma tego problemu", ale tylko dlatego, że nikt z nas nie widział jego kodu, więc nie wiemy co tam jest - równie dobrze może być napisany z użyciem najgorszych metod programistycznych.No jasne... W oprogramowaniu komercyjnym wszystko zawsze działa (; A jak jest błąd to od razu go poprawiają, a nie np. poprawiają go dopiero w nowej głównej wersji, którą musisz sobie kupić... Jeśli Twoja teoria byłaby prawdziwa, to oprogramowanie komercyjne zwykle kończyłoby się na wersji 1.0, bo przecież po co kolejne, skoro nie ma w nim błędów? Ewentualne nowości pojawiają się tak rzadko (nowa architektura ARM, nowa rodzina procków, nowy standard debuggowania), że nowa wersja wychodziłaby max raz na rok.Istotny jest też drobny fakt, że rozwojem oprogramowania komercyjnego kieruje marketing - jeśli ktoś w danej firmie uzna, że ta poprawka nie należy Ci się za darmo, to jej nie dostaniesz, zostanie wprowadzona w kolejnej wersji, którą znów będziesz musiał (ponownie!) kupić.No i też zapomniałeś o tym, że firmy powstają i upadają. I pewnego dnia Twoje IDE może przestać działać, bo firma która je sprzedaje upadła, a soft do działania wymaga np serwera autoryzacji (częsta praktyka obecnie). Goodbye. Taki problem nie dotyczy opensource. Pozatym czy wiązanie się z zamkniętym oprogramowaniem nie jest również vendor-lock-in? Niby C to C, ale wiele dodatkowych bajerów jest tylko w Keilu albo tylko w IAR, nie mówiąc już o typowych różnicach jak przerwania.Wbrew pozorom w opensource jest dokładnie tak jak piszesz - nad projektem pracuje konkretna grupa ludzi (maintainers), którzy "zatrudniają" klepaczy kodu. Maintainerów - ludzi z prawami zapisu do repozytorium - nie jest wcale tak dużo, w OpenOCD są to chyba 2 czy 3 osoby, w Linuxie pewnie mniej ludzi niż dyrektorów Microsoftu.Doskonałym przykładem zastosowania opensource tam gdzie liczy się time to market jest rynek routerów. Czemu nie są postawione na jakimś "porządnym" systemie tylko na tym opensourceowym badziewiu? Dodatkowo wydaje mi się, że schematy które publikuje TI (noty aplikacyjne czy takie tam) są w KiCadzie. Wielu producentów rdzeni wspomaga rozwój portu GCC na swoją platformę (nawet ARM!), rdzenie na które nie ma GCC nigdy nie są popularne wśród "mas". Czy ARMy byłyby dziś tu gdzie są, gdyby nie było OpenOCD, GCC i JTAGów na FT2232? Gdyby nie było konkurencji, Keil mógłby spokojnie kasować za swój debugger 5000$, bo niby czemu nie - i tak nie miałbyś wyjścia. Gdyby nie cały ten opensource ani Ty, ani ja nie wiedzielibyśmy nic o ARMach, tak samo jak nie wiemy nic o np. BlackFinach czy Renesasach.4\/3!!

tymon_x · Answer

Ano, że SVF jest formatem przemysłowym i pod niego działał bezbłędnie. Można nim zaprogramować AVR czy skonfigurować PLD. Xilinx wprowadził pewien smaczek w kilku polecaniach, trzeba było dostosować SVF Player'a.Jakoś Linux mnie nie zawiódł, fakt że przygotowanie własnej platformy hardware pod niego troszkę trzeba napracować, ale robisz to tylko raz. Później zmieniasz jak chińczyk, tylko obudowę pod projekt. Aplikacje piszę normalnie w Java, C, C++ w Qt na PC Linux Version, kompilacja pod ARM, kopiowanie na kartę SD czy ethernet -> NFS i wio, trwa to moment. A Linux jest number uno jeśli chodzi o serwery. Większość adminów ma skrzywienia po komercyjnych projektach, fajnie to wygląda na pudełku, a później może być kłopot, jeśli nowe produkty nie są kompatybilne wstecz z starszą wersją, bo producent trzyma kody.

gaskoin · Answer

tymon -> Linux -> Linuksa !

Linuksy i oprogramowanie opensource ma jedną bardzo poważną wadę, jeśli chodzi o komerchę. Tak naprawdę to jak coś działającego na opensourcie się wykrzaczy i przez to jakaś firma straci kupę kasy/komuś stanie się krzywda to nie ma kogo za bardzo za to sądzić. Projekt jest otwarty i do użytku na własną odpowiedzialność. Wiele firm się tego boi - bo nie ma na to żadnej gwarancji.

Ja osobiście sam używam Linuksa i nie mogę nic zarzucić. Brakuje paru rzeczy Windowsowych ale to głównie nadrabiam virtualboxem. Dużo osób krytykuje ten system operacyjny, zachwalając Winde i niektóre programy jakie na nią powstały. Jednak ta sama ilość osób nie wie, że na Linuksa napisano więcej programów niż na Windowsa, a wiele Windowsowych progów to tylko porty z Linuksa. GCC też jest portem z Linuksa bo pierwotnie tylko na niego powstało. Z resztą w większości przypadków kompilacja GCC jest możliwa tylko za pomocą Cygwina albo MinGW - to są linuksowe shelle z pomocą których przeportowanie programów stało się trochę prostsze. GCC jest chyba napisane dla wszystkich platform, ostatnio zamówiłem sobie TI launchpad i na ich stronie nawet są odnośniki jak postawić środowisko do programowania/kompilowania/debugowania na Linuksie.

Jeśli chodzi o niestabilność to Linuksy wręcz nie lubią restartów, nie zdarzyło mi się, żeby komputer po tygodniowym non stop działaniu zaczął zamulać czy cokolwiek innego mu dolegało. Byłem kiedyś w pewnej firmie i w laboratorium stały dwa komputery (na windzie) sterujące pewnym procesem przemysłowym. Na pytanie po co dwa komputery, usłyszałem odpowiedziedź, że Windows jest niestabilny więc drugi komputer jest w razie gdyby pierwszy padł co się im często zdarza. Gdzie tu niestabilność ?

Z resztą spójrzcie na nowego Win7 - dużo pomysłów jest zerżniętych z lina. Wiele osób się jara jakimiś cud-bajerami. To wszystko od stu lat już jest w Linuksie

Ale fakt - trzeba być nieco ogarniętym, żeby postawić sobie wszystko pod HW. Plus jest taki, że robi się to raz. Postawienie samego Linuksa (wraz ze sterownikami i podstawowym oprogramowaniem) trwa około 5-10 minut, przy czym z 4 minuty się pobierają pakiety językowe.

Nie krytykujcie czegoś czego nigdy nie spróbowaliście

McMonster · Answer

Doceniam entuzjazm, ale w tym miejscu muszę się wtrącić. Stwierdzenie, że Linux to numer jeden na serwery jest karkołomne i zostawiłbym je osobom, które mają doświadczenie w tej dziedzinie. Powód jest prosty, niewielu zapaleńców i entuzjastów tego systemu miało realny kontakt z alternatywami, szczególnie serwerowymi Windowsami, a powyższa wypowiedź strasznie trąci zakurzonymi schematami. Jak przyszedłem do obecnej pracy to byłem w lekkim szoku, że chociaż prawie wszyscy Linuksa w małym palcu mają, to ze wszystkich stron otaczają ich okna, nawet na prywatnych laptopach. Pingwinek krył się jedynie po jakichś zapomnianych maszynach fizycznych wirtualnych i może jednym ważnym serwerze. Po roku siedzenia tutaj już nie mam wątpliwości, że nie jest to zły układ, bo poznałem tutaj możliwości Windowsów, o których mi się nawet nie śniło i zrozumiałem, że nic nie jest czarne lub białe, Linux jest znakomity w wielu dziedzinach, ale i Windows ma masę swoich zalet i możliwości.Nic nie jest białe, ani czarne, nie należy ślepo wierzyć w jedynie słuszne rozwiązanie (jak ja kiedyś w Linuksa) i należy się cieszyć z tego, że jest wybór i alternatywa. Przez ładnych parę lat byłem zapalonym linuksiarzem (i nie przestałem nim być), nie jest istotne tutaj dlaczego, ale wróciłem na Windowsa i jest mi z nim dobrze. Dopiero moja obecna praca mi to uświadomiła, bo wcześniej Windows Server znałem jedynie z legend i obrazków, teraz jestem bogatszy o doświadczenie własne i możliwość wyboru, który system w danym wypadku zastosować, co się też przekłada na większą elastyczność w przyszłej pracy administratora.

nsvinc · Answer

Na pewno by utrudnił. Kiedyś, gdy zaczynałem z AVRami, to skompilowany wsad wrzucało się przez programator z portu LPT - i powstawało takie nierozwiązywalne misterium jak np. nie działa jakiś EEPROM po SPI. Nie działa i już... I teraz zgadywanka dlaczego nie działa, trwała wtedy kilka dni, i dobrą setkę wgrywania kodu w procesor. Teraz, dzięki debuggerowi, takie szopki rozwiązuje się w godzinkę i w trzech iteracjach...W szczególności, że biedny LPCek w pewnym układzie został praktycznie wyeksploatowany do granic możliwości. Bez debuggera ciężko...A praca na samych ARMach to nie jest vendor lock-in? Tak samo jest, tyle że na znacznie mniejszą skalę, niż takie AVRy i bascom, czy biblioteka do STM32...Nie chodzi mi o to, że Keil jest jedyny właściwy. Ale właśnie za to, że korzystając z niego mogę sobie pozwolić na olewanie makefile'ów, konfiguracji debuggera, konfiguracji tego, tamtego, grzebiąc w plikach tekstowych napisanych szyfrem, tylko (cytując kolegę z forum) "klikam nowy projekt i nadupczam w C"...Heh, keil to jest ARM, więc wątpię czy ARM będzie robić pod siebie i wycofa jeden z najlepszych komercyjnych środowisk do pracy z ich własnymi prockami...A jakby już tak się stało, że wycofają, to siłą rzeczy będę zmuszony korzystać z innych środowisk - dla mnie przesiadka nie jest problemem jako takim. Po prostu ani nie ma sensu, ani ochoty, przesiadać się z lepszego kompilatora na gorszy - kompilator Keila (nie)stety wypada znacznie lepiej pod kątem wydajności kodu wynikowego niż GCC.Nie byłyby. Ale przecież ja nic nie mam do OS. Oczywiście że ARMy zyskały popularność dzięki tanim i łatwo dostępnym narzędziom. Ale z drugiej strony - czy wyznacznikiem jakości rdzenia/procka jest jego popularność wśród mas? Pierwszym z brzegu przykładem są procki Infineon'a..."Wiemy", ile trzeba. Nawet "mamy" starter kit z narzędziami za free, i to nie jeden. Wystarczyło "gdzieś" zadzwonić i "gdzieś" się zarejestrować. To już była moja decyzja, czyich procków będę używać... Dodano po 15 [minuty]: Ja robię restart średnio rzadziej niż raz na dwa tygodnie, o ile nie katuję swojego systemu wypaczonymi eksperymentami z oprogramowaniem. Odporność? Wybitna. Jednocześnie uruchomiony keil, altium, opera, bds, open office writer, pspad, terminal, foxit, kilkanaście okien eksploratora windows, i sporo śmieci w trayu - NIC nigdy się nie przycina podczas normalnej pracy...Ale czy to nie jest oczywiste? Ktoś musi brać odpowiedzialność na siebie. Systemy o wysokiej niezawodności/zaufania nigdy nie staną na OS - przecież musi być ktoś, na kogo można nakrzyczeć i zgarnąć fortunę z odszkodowania. Jak ty byś sobie inaczej wyobrażał cały ten rynek?...Chyba nikt oprócz mnie jeszcze nie krytykował, a ja właśnie napisałemI linucha pod VMWare tez miałem (ubuntu właśnie) który nawet prawidłowo nie chciał widzieć zasobów smb, ani tym bardziej "folderów udostępnionych", przez co musiałem specjalnie postawić FTPa i w sztuczny sposób przenosić pliki z A do B w obrębie tego samego komputera :/ . A VB po prostu nie chciał się uruchomić, i nawet błędami nie rzygał - po prostu nie działał (dlatego tez VMWare)...

gaskoin · Answer

Widzę, że Ci się spodobało

Opensource ma jedną wielką zaletę - pozwala hobbystom poczuć namiastkę prawdziwego profesjonalnego sprzętu

nsvinc wrote:

Ale czy to nie jest oczywiste? Ktoś musi brać odpowiedzialność na siebie. Systemy o wysokiej niezawodności/zaufania nigdy nie staną na OS - przecież musi być ktoś, na kogo można nakrzyczeć i zgarnąć fortunę z odszkodowania. Jak ty byś sobie inaczej wyobrażał cały ten rynek?...

Ale ja nie mówię, że to źle niedobrze, precz, won. Tu już wchodzi biznes, a nie niezawodność. Trzeba to też rozgraniczyć, bo co w przypadku, gdy gość ma wybrać - kupić system który pada 17 razy w ciągu dnia, ale jest wpierany przez firmę (gwarancja), czy postawić na darmowym osie, padającym 17 razy w ciągu 1700 lat ? Takie tam pytanie z cyklu filozofie na dobranoc:P

nsvinc · Answer

A tego nie kminię... Mnie nie boli sam OS, tylko to, ze softy OS nie działają!... Linux - męka. Ride - męka. JTAG na FT2232 - męka. Yagarto - męka. OpenOCD - męka... Jeśli softy open source byłyby takie, że nie musiałbym myśleć o co chodziło programistom tego softu, a tylko zrobiłbym "klik" i mógł korzystać z danej funkcjonalności, to też byłbym zwolennikiem. Ale tak nie było, przynajmniej w moim wypadku. Jak zaczynałem z ARMami (stm32), to był Ride i ich x-Link. Nie działa... W trybie natychmiastowym postawiłem yagarto i podłączyłem JTAGa na ft2232 - nie działa, OOCD na mnie nakrzyczał że cośtam. Marnuję godziny aby dowiedzieć się wtf, szukam w necie - nikt nic nie wie. A za 10 godzin projekt do oddania...A co do stabilności - jeszcze jedno. To ja nie mam ani magicznego komputera, ani magicznego OSa - ja po prostu - korzystając z windy od urodzenia - umiem z tym systemem rozmawiać tak, że nie będzie mi się wykrzaczał. Bo "debil pokaleczy się nawet marchewką", i zajezdzi tak samo skutecznie linuxa, jak i winde... I kolejnym faktem jest, że wszystko M$owe nowsze od XP to już niestety szajs, i nigdy sobie tego na swoim kompie nie postawię - jeszcze się na mnie obrazi ;] Dodano po 5 [minuty]: Właśnie, biznes. Jak będzie prosperować komercyjna firma, jeśli stworzy profesjonalny system za kupę kasy który padnie 17 razy w ciągu dnia? Nie mówię o M$, bo to ewenement, ale w każdym innym przypadku, firma kasuje - firma wspiera i ponosi konsekwencje w razie awarii. Chyba lepiej wziąć odszkodowanie wielokrotnie przekraczające rzeczywiste straty od komercyjnej firmy gdy sprzęt psuje się 17 razy dziennie, niż użyć cudownego opensource'a, za którego "w razie wu" nikt nie odpowiada...

TWl · Answer

Świetnym przykładem tej legendarnej stabilności jest wspomniany przez Kolegę Altium, który przy z wersji na wersję wiesza się coraz częściej i np.na niezbyt skomplikowanej karcie PCIe (6 warstw) potrafi rzucać wyjątkami lub po prostu wywalać się co pół godziny. Do małych płytek (takich pod LPC1xxx) Kicad na prawdę wystarczy, a jestem pewien, że w przyszłości i do bardziej złożonych projektów będzie się nadawał.Ochh. Windows też taki ma, tylko bardziej upierdliwy. Jest używany do komunikacji komercyjnego userlandu z komercyjnymi sterownikami (pisanie driverów pod Win32/64 to dopiero przyjemność!), po sobie tylko znanych komercyjnych protokołach. Developerzy Linuksa przynajmniej starają się ustandaryzować ioctl-e dla określonych kategorii sprzętu. Code: text Expand Select all Copy to clipboard
BOOL WINAPI DeviceIoControl(
  __in         HANDLE hDevice,
  __in         DWORD dwIoControlCode,
  __in_opt     LPVOID lpInBuffer,
  __in         DWORD nInBufferSize,
  __out_opt    LPVOID lpOutBuffer,
  __in         DWORD nOutBufferSize,
  __out_opt    LPDWORD lpBytesReturned,
  __inout_opt  LPOVERLAPPED lpOverlapped
);
PzdrTWlPS. Rozumiem, że masz licencje na te wszystkie profesjonalne, dopracowane komercyjne programy?

Freddie Chopin · Answer

Wg mnie jesteś w tzw mylnym błędzie - wiele projektów opensource tak naprawde jest wydawanych przez jakieś firmy, tyle że za darmo (albo i nie) i udostępniają kod. OpenOffice, Red Hat, Ubuntu i Virtual Box jako przykłady pierwsze z brzegu. To po pierwsze. Po drugie zaś istnieją specjalne wersje oprogramowania, przeznaczone do aplikacji krytycznych, pierwszym z brzegu przykładem jest SafeRTOS, odmiana FreeRTOSa. Nie są darmowe, ale po zakupie dostaje się kod, wsparcie i gwarancję.Co RIDE ma wspólnego z opensource, bo wg mnie nic. To że wewnątrz masz GCC jeszcze nie czyni z tego środowiska opensource - do Keila czy IARa też można podpiąć GCC.Czy nie sądzisz, że gdybyś od urodzenia używał Linuxa, to teraz pisałbyś dokładnie odwrotnie?Przecież jest sto sposobów debuggowania bez debuggera (; Inaczej - byłoby ciężej bez JTAGa, ale o ile ciężej? Wg mnie powiedzmy że max 20%.Jeśli opierasz to stwierdzenie na znanych z sieci "porównaniach", to muszę niestety przypomnieć, że są typową zmanipulowaną ściemą. Z racji tego, że Keil wspierany jest przez ARMa to na pewno jest bardzo wydajny, ale czy GCC jest znacznie gorszy? Ponownie - przypuszczam, że różnica procentowa jest jednocyfrowa, a do tego w typowych zastosowaniach i tak nie ma to znaczenia, bo pamięć jest tania, a w 90% projektów i tak 90% czasu układ krąży w pustych pętlach oczekiwania, a te każdy kompilator przetłumaczy tak samo.Oj to był tylko przykład... Pozatym myślisz, że gdybym ja zadzwonił gdzie trzeba, to też mi przyślą za darmo starter kit i narzędzia? Nie myl zastosowań biznesowych z hobbystycznymi (;4\/3!!

Jado_one · Answer

No włąsnie.....jak dla mnie np. przy transmisjach zewnetrznych miedzy prockiem, a jakims innym układem bardziej mi sie przydaje analizator stanów logicznych (soft chodzi tez pod linuxem - natywnie ) - od razu widzę, co się krzaczy w transmisji. W tym wypadku "widzisz i masz" Oczywiscie jak się do tego doda debugger, to jest jeszcze milej i szybciej No to widzę, że jest więcej kolegów linuxowców-elektroników.... Miło....Ten system ma swoje zalety, ale ma tez i swoje wady - jak sie je mniej wiecej pozna, to człowiek porusza się bez większych problemów. Tylko nie można za często robić upgrade'u systemu (i róznych bibliotek), bo to co działało wcześniej, może przestać działać Poł biedy jak jest nowsza wersja programu, ale jak projekt nie rozwijany, to może być problem....Często to człowiek w komputerze sam sobie więcej namąci (grzebactwo) niż mu sie sam system rozjedzie.Linux ma tą zaletę, że można sobie programy składać z róznych klocków (mniejszych programów), łaczyć w większe środowiska - jak komu jest wygodnie. Ja np. edytuje sobie w Geany, do którego można podpinać - do każdego projektu inne - rózne kompilatory, skrypty, programatory itp.... Jednen klik i zmiana projektu na inny, i przeszliśmy np. z ASM pod PIC na C dla ARM'ow.Ale oczywiście to wymaga wcześniej pokonfigurowania tych skryptów, itd....ale to normalne pod linuxem Mnie już to nie przeszkadza....