Tworzenie oprogramowani dla systemów wbudowanych w firmach

Tutaj umieszczamy tematy związane z językami programowania niepasującymi do innych działów.
Regulamin forum
Temat prosimy poprzedzić nazwą języka umieszczonego w nawiasach kwadratowych np. [Pascal].
Awatar użytkownika
StaryAnoda_NEW
User
User
Posty: 103
Rejestracja: środa 04 kwie 2018, 16:48

Tworzenie oprogramowani dla systemów wbudowanych w firmach

Postautor: StaryAnoda_NEW » sobota 30 cze 2018, 14:48

Hej

Mam pytanie do osób którzy zarabiają na chleb tworząc oprogramowanie dla systemów wbudowanych.

Mam dowolny mikrokontroler, i jednym z zewnętrznych modułów jest na przykład akcelerometr LSM303D. I tutaj moje pytanie czy pisząc obsługę takiego akcelerometru robicie całą mapę pamięci takiego układu, nawet wtedy jeżeli wiecie, że nigdy niektórych funkcji nie będziecie używać ?

W jaki sposób konfigurujecie poszczególne wartości w rejestrach?
Czy bardziej w taki rozbudowany sposób:

Kod: Zaznacz cały

typedef enum { X_AXIS_DISABLED = 0b0, X_AXIS_Enabled = 0b1} AXEN_Type;
typedef enum { Y_AXIS_DISABLED = 0b0, Y_AXIS_Enabled = 0b1} AYEN_Type;
typedef enum { Z_AXIS_DISABLED = 0b0, Z_AXIS_Enabled = 0b1} AZEN_Type;

typedef enum
{
   CONTINOUS_UPDATE = 0b0,
   OUTPUT_REGISTER_NOT_UPDATED_UNTIL_MSB_AND_LSB_HAVE_BEEN_READ = 0b1
} BDU_Type;

typedef enum
{
   POWER_DOWN_MODE = 0b0000,
   Frequency_3_125Hz = 0b0001,
   Frequency_6_25Hz = 0b0010,
   Frequency_12_5Hz = 0b0011,
   Frequency_25Hz = 0b0100,
   Frequency_50Hz = 0b0101,
   Frequency_100Hz = 0b0110,
   Frequency_200Hz = 0b0111,
   Frequency_400Hz = 0b1000,
   Frequency_800Hz = 0b1001,
   nFrequency_1600Hz = 0b1010
} AODR_Type;

typedef union
{
   struct
   {
      AXEN_Type AXEN :1;
      AYEN_Type AYEN:1;
      AZEN_Type AZEN :1;
      BDU_Type BDU :1;
      AODR_Type AODR :4;
   };
   uint8_t byte;
}LSM303_REG_CTRL1_VALUE;

LSM303_REG_CTRL1_VALUE REGISTER_CONTROL_1 =
   {
         .AXEN = X_AXIS_Enabled,
         .AYEN = Y_AXIS_Enabled,
         .AZEN = Z_AXIS_Enabled,
         .BDU = CONTINOUS_UPDATE,
         .AODR = Frequency_25Hz

   };
   buffer = REGISTER_CONTROL_1.byte;
   
   TWI_write(LSM303_DEVICE_ID, LSM303_CTRL1, buffer);


Czy w taki prostszy sposób:

Kod: Zaznacz cały

TWI_write(LSM303_DEVICE_ID, LSM303_CTRL1, 0b01000111); // X_AXIS_Enabled, Y_AXIS_Enabled, Z_AXIS_Enabled, CONTINOUS_UPDATE, Frequency_25Hz


Jeżeli ktoś ma jakieś przemyślenia to bardzo proszę o podzielenie się nimi.

Pozdrawiam
StaryAnoda

 ! Wiadomość z: wojtek
temat przeniosłem z "ohydnego parku" tu jednak bardziej pasuje ;)

Awatar użytkownika
Antystatyczny
Geek
Geek
Posty: 1168
Rejestracja: czwartek 03 wrz 2015, 22:02

Re: Tworzenie oprogramowani dla systemów wbudowanych w firmach

Postautor: Antystatyczny » sobota 30 cze 2018, 18:52

Co prawda nie zarabiam klepiąc kody, ale pytałeś mnie o zdanie, więc się wypowiem. Na ogół staram się przygotować kompletny zestaw funkcji do obsługi danego elementu (tutaj akcelerometru). Nie dość, że tworzę kompletną mapę pamięci, funkcje obsługujące wszystkie główne "umiejętności" modułu, to całość pisana jest w taki sposób, by ten kawałek oprogramowania nie miał pojęcia, na jakim procku pracuje (oderwanie od sprzętu). Podczas inicjalizacji sprzętu przekazuję do funkcji wskaźniki na funkcje najniższego poziomu, które załatwiają sprawę komunikacji z modułem. Aha, osobiście wolę pierwszą wersję kodu, który przedstawiłeś.
"The true sign of intelligence is not knowledge but imagination" Albert Einstein.

SuperGość
Uber Geek
Uber Geek
Posty: 2346
Rejestracja: piątek 04 wrz 2015, 09:03

Re: Tworzenie oprogramowani dla systemów wbudowanych w firmach

Postautor: SuperGość » sobota 30 cze 2018, 19:50

Hmm generalnie, to w przypadku firm, które projektują urządzenia oparte na mikrokontrolerach i piszą dla nich oprogramowanie, a potem to sprzedają i żyją z produkcji, to przy wyborze dla danego projektu np. mikrokontrolera, to najpierw sprawdzany jest jego status albo inaczej mówiąc czas życia czyli na jak długo można liczyć nieprzerwane dostawy. Nikt nie zastanawia się wówczas nad tym aby pisany program był "uniwersalny", tylko aby był zgodny z założeniami, szybko zaprojektowany, przetestowany i wdrożony. Oczywiście istnieją określone zasady dotyczące tworzenia kodu ale nie zakładają one uniwersalności.
Właśnie teraz startujemy z nowym dużym projektem i zaczęliśmy od wyboru SoM (System on Module), bo tym razem postanowiliśmy skorzystać z czegoś już "gotowego" (liczy się czas realizacji projektu) i jednym z pytań jakie zadajemy jest właśnie czas przez jaki możemy liczyć na niezagrożone dostawy (minimum 10 lat)
Może nie jest to odpowiedź wprost na twoje pytanie (a nawet na pewno) ale chciałem tylko pokazać, że co innego jest pisanie programów dla nauki, dla pewnej zabawy umysłowej czy pasji, a co innego gdy masz postawione konkretne zadanie i czas na jego realizację.

Awatar użytkownika
mokrowski
User
User
Posty: 190
Rejestracja: czwartek 08 paź 2015, 20:50
Lokalizacja: Tam gdzie Centymetro

Re: Tworzenie oprogramowani dla systemów wbudowanych w firmach

Postautor: mokrowski » sobota 30 cze 2018, 23:10

@wojtek ale zrobienie porządnie zwykłej mapy pamięci ew. rejestrów/szyn to nie "akademickie dłubanie w kodzie opóźniające dostarczenie produktu". To i tak powinien albo zrobić vendor albo powinno być zrobione (wiadomo że ze względu na koszty najlepiej przez "innych") na podstawie dokumentacji. Tu odpowiedź to nie jest zrobić czy nie zrobić tylko bez tego się nie da!
Inną sprawą jest już modularyzacja czy elegancja kodu tudzież jego patologiczna odmiana osobiście nazywana "wizażem kodu" :) (kreseczki, szlaczki, licencyje w każdym skrypcie, znaczniki czasu i syganturki "To zrobił Zenek"....) Jeśli o niej pisałeś, to się zgadzam. Zrobienie kodu od "szybko piszcie aby działał reszta to drut i plaster" do "w firmie wiemy jak tego użyć i ma to sens ale to nie nadaje się do publikacji jako źródła na wolnym rynku" to czynnik x3. Od tego ostatniego do "mamy produkt którego źródła pokażemy" to następne ~3x. Tak więc od spagetti do "wycyzelowanego produktu" z dokumentacją, przykładami, sensownym małym sprzężeniem i wysoką spójnością to x9/x10. Za to nikt nie chce płacić.
@ StaryAnoda_NEW zrób mapę rejestrów bo na początkowym etapie naprawdę nie wiesz jakich funkcji użyjesz i czy nie trzeba będzie "merdać rejestrem" na pierwszy rzut oka nie związanym z funkcjonalnością. Rodzaj reszty implementacji to niestety odpowiedź "to zależy". Zależy od krytyczności systemu, standardów branżowych (Medical, Automotive, Aerospace.... ), stosowania bądź nie jakiegoś OS, procesu wytwarzania oprogramowania, obecności strony trzeciej w trakcie certyfikacji czy ogólnie własnego pionu QA.
Zresztą im bardziej wykwalifikowany zespół, tym lepszy w utrzymaniu kod pisze i tym łatwiej ustalić sensowne kryteria jego odbioru.
,,Myślenie nie jest łatwe, ale można się do niego przyzwyczaić" - Alan Alexander Milne: Kubuś Puchatek

SuperGość
Uber Geek
Uber Geek
Posty: 2346
Rejestracja: piątek 04 wrz 2015, 09:03

Re: Tworzenie oprogramowani dla systemów wbudowanych w firmach

Postautor: SuperGość » niedziela 01 lip 2018, 05:37

Aby było jasne, temat postu "Tworzenie oprogramowani dla systemów wbudowanych w firmach" jest bardzo ogólny, i do tego głownie się odniosłem pisząc - "....tylko aby był zgodny z założeniami, szybko zaprojektowany, przetestowany i wdrożony" - oraz - "....że co innego jest pisanie programów dla nauki, dla pewnej zabawy umysłowej czy pasji, a co innego gdy masz postawione konkretne zadanie i czas na jego realizację" - to wcale nie oznacza "bylejakości", tylko czysty rachunek ekonomiczny ;) - ten rachunek aby było jasne obejmuje też koszty po wdrożeniu, nie ma więc mowy o partaninie czy bylejakości.

Awatar użytkownika
StaryAnoda_NEW
User
User
Posty: 103
Rejestracja: środa 04 kwie 2018, 16:48

Re: Tworzenie oprogramowani dla systemów wbudowanych w firmach

Postautor: StaryAnoda_NEW » niedziela 01 lip 2018, 15:02

Ok fajnie, że kilka osób się wypowiedziało. Dziękuję ale czekam no wypowiedzi innych osób które czają się w zaroślach ;)

Awatar użytkownika
GrumpyRez
User
User
Posty: 224
Rejestracja: poniedziałek 04 cze 2018, 09:19

Re: Tworzenie oprogramowani dla systemów wbudowanych w firmach

Postautor: GrumpyRez » niedziela 01 lip 2018, 17:08

W sumie ja to nie mam czego dodawać, Wojtek tutaj słusznie zauważył, że w wielu przypadkach liczy się Time To Life, oraz koszt/czas wdrożenia projektu.
U mnie podobnie, nikt nie siedzi nad opisywaniem wszystkich możliwych funkcji, ot to co jest potrzebne do projektu. Bibliotekę zawsze można rozszerzyć o potrzebne funkcjonalności z czasem. Na 'czas' projektu, robi się to co niezbędne, testuje, uruchamia (co zajmuje lwią część czasu), a potem ewentualnie po wdrożeniu, jeżeli jest potrzeba rozwinięcia funkcjonalności dopisuje brakujące funkcje.

Awatar użytkownika
StaryAnoda_NEW
User
User
Posty: 103
Rejestracja: środa 04 kwie 2018, 16:48

Re: Tworzenie oprogramowani dla systemów wbudowanych w firmach

Postautor: StaryAnoda_NEW » niedziela 01 lip 2018, 17:40

reza_sprzedaż pisze:W sumie ja to nie mam czego dodawać, Wojtek tutaj słusznie zauważył, że w wielu przypadkach liczy się Time To Life, oraz koszt/czas wdrożenia projektu.
U mnie podobnie, nikt nie siedzi nad opisywaniem wszystkich możliwych funkcji, ot to co jest potrzebne do projektu. Bibliotekę zawsze można rozszerzyć o potrzebne funkcjonalności z czasem. Na 'czas' projektu, robi się to co niezbędne, testuje, uruchamia (co zajmuje lwią część czasu), a potem ewentualnie po wdrożeniu, jeżeli jest potrzeba rozwinięcia funkcjonalności dopisuje brakujące funkcje.


Ok dzięki za odpowiedź.

Awatar użytkownika
elvis
Posty: 12
Rejestracja: piątek 23 mar 2018, 09:49

Re: Tworzenie oprogramowani dla systemów wbudowanych w firmach

Postautor: elvis » poniedziałek 02 lip 2018, 23:10

Ja dodam tylko, że jest kilka powodów dla których lepiej NIE dodawać od razu wszystkich rejestrów, opcji itd itp.
Pierwsza sprawa to możliwe modyfikacje projektu. Powiedzmy, że dostajemy zadanie napisania drivera dla LSM303 - siedzimy po nocach, piszemy piękny sterownik, który ma milion nikomu niepotrzebnych funkcji. A za tydzień przychodzi nowa decyzja - zmiana na inny układ... Stosowanie "leniwej" stragegii czasem jest wręcz optymalne.
Druga sprawa to testowanie. Najczęściej brak kodu jest lepszy niż niepoprawny kod. Skoro wpiszemy wszystkie rejestry dostępne w dokumentacji to powinniśmy je również przetestować. Przysłowiowy "czeski błąd" i mamy niepoprawnie podefiniowane rejestry. Problem polega na tym, że samo ich wypisanie do dużo pracy, ale pomijając testowanie ryzykujemy że wprowadzimy błąd, który odbije się czkawką dużo później (tym bardziej, że wtedy nikt już nie będzie pamietał, że kod nie jest przetestowany w 100%, a ponieważ reszta działa, więc każdy ufa że sterownik jest ok).
Moim zdaniem lepiej napisać mniej rozbudowany program, ale poprawny i przetestowany, a w miarę jak będą potrzebne nowe opcje, można je bez problemu dodać (testując oczywiście).

Awatar użytkownika
mokrowski
User
User
Posty: 190
Rejestracja: czwartek 08 paź 2015, 20:50
Lokalizacja: Tam gdzie Centymetro

Re: Tworzenie oprogramowani dla systemów wbudowanych w firmach

Postautor: mokrowski » wtorek 03 lip 2018, 10:30

elvis pisze:Ja dodam tylko, że jest kilka powodów dla których lepiej NIE dodawać od razu wszystkich rejestrów, opcji itd itp. Pierwsza sprawa to możliwe modyfikacje projektu.

I to jest narzędzie którym obsługujesz zmiany w projekcie?!! Braki definicji warstwy sprzętowej? Zdefiniowanie rejestru (piszę tylko o definicji a nie o dodawaniu zachowania czyli funkcji/metod) określa jednoznacznie że dany zakres adresacji jest zajęty. Czy to na szynie czy na mapowanej pamięci.
elvis pisze:...siedzimy po nocach,

Nie będę tego komentował. Powody mogą być tylko patologiczne... jeśli tak jest to "źle się dzieje tak w projekcie" (jak i być może w firmie).

Definicję warstwy sprzętu należy bezwzględnie zrobić. Powody są normatywne (mówi o tym standard Autosar, odpowiednie dla Med., Ind. Aero.... itd.). Daje to także możliwość sprawdzania statycznego kodu ze względu na konflikty adresacji co jest bezwzględnie konieczne w systemach zachowujących określony poziom bezpieczeństwa Nie stosujesz, nie dyskutuję bo nie musisz. Zrozum jednak że to jest zła praktyka uniemożliwiająca dostarczenie produktu w ww. sektorach. W moim przypadku jestem odpowiedzialny za QA oraz przygotowanie do certyfikowania poprawności kodu i (nie ukrywam) że zajmuję się "tępieniem" złego podejścia :/

Oczywiście że nie robi się funkcjonalności zbędnych na danym etapie lub w projekcie. Sprzęt należy jednak zdefiniować aby mieć nad nim kontrolę (na minimalnym poziomie "to jest zajęte", "tu się coś odzywa", "nie dotykaj tego obszaru bo... ").

Poza tym w dobrze "upilnowanej architekturze", wiążesz do interfejsów warstwy wyższej a nie niższej co jest także złą praktyką często sprzedawaną jako "tak się robi".
elvis pisze:Skoro wpiszemy wszystkie rejestry dostępne w dokumentacji to powinniśmy je również przetestować.

To zależy od rodzaju testu/testów które masz w projekcie na danym etapie. Tu także standardy branżowe mówią wyraźnie czy wpisanie definicji rejestru równoznaczne jest z koniecznością jego testu :) Podpowiem że nie jest.
elvis pisze:Problem polega na tym, że samo ich wypisanie do dużo pracy..

Mam być bezpośredni? Za to Ci płacą :) Także i mi bym tego pilnował :) NIe wiem także czy to tak dużo pracy. Często nagłówek daje vendor lub robisz copy/paste z dokumentacji poddając to prostej obróbce.

Warto zauważać różnicę pomiędzy definicją zakresu adresów sprzętu (która nie ma nic wspólnego z domeną rozwiązania i jest warstwą techniczną) i definiowaniem zachowania (które ma wiele wspólnego z domeną rozwiązania). To drugie wpływa bezpośrednio na czynniki sukcesu i przyjęcie produktu przez klienta oraz jego koszt. Jest odzwierciedleniem jakości zewnętrznej. To pierwsze nie (przysłowiowe krasnoludki które biegają i robią coś w tej kostce) i jest odzwierciedleniem jakości wewnętrznej. Tym większe zdziwienie że kolokwialnie "robienie sobie siary i problemów na poziomie technicznym" sprzedawane jest jako "praktyka różni się od teorii" :)

Każda firma ma własny cykl produkcyjny, własne standardy jakości oraz zespół tworzący oprogramowanie. Czasem jednak zmuszona jest do standaryzacji procesu produkcji. Złe praktyki lub "przyzwyczajenie które zostało zracjonalizowane" (w sensie psychologicznego pojęcia racjonalizacji), eliminują ją z danego sektora.

Tu jest cała masa tak literatury jak i opracowanych procesów dla danych sektorów. W tym wątku nie było jednak pytania o takie źródła więc nie będę się rozpisywał i podam minimalną ilość:
16 strona, wymagania odnośnie modułu dla Autosar: https://www.autosar.org/fileadmin/user_ ... eneral.pdf
C++14 w systemach krytycznych... co wolno a czego nie oraz odniesienie do MISRA: https://www.autosar.org/fileadmin/user_ ... elines.pdf

Starczy tego udowadniania że wielbłąd ma garby...
,,Myślenie nie jest łatwe, ale można się do niego przyzwyczaić" - Alan Alexander Milne: Kubuś Puchatek

Awatar użytkownika
elvis
Posty: 12
Rejestracja: piątek 23 mar 2018, 09:49

Re: Tworzenie oprogramowani dla systemów wbudowanych w firmach

Postautor: elvis » wtorek 03 lip 2018, 10:55

mokrowski pisze:I to jest narzędzie którym obsługujesz zmiany w projekcie?!! Braki definicji warstwy sprzętowej?

Przeczyaj co napisałem ze zrozumieniem - nie zachęcam po pomijania wartwy abstrakcji, czy definicji sprzętu. Chodziło mi tylko o to, że nie ma konieczności definiowania wszystkich funkcji od razu.
Natomiast z tego co obserwuję większość firm jako narzędzia za obsługi zmian w projektcie używa Worda i Excela.

mokrowski pisze:Zdefiniowanie rejestru (piszę tylko o definicji a nie o dodawaniu zachowania czyli funkcji/metod) określa jednoznacznie że dany zakres adresacji jest zajęty. Czy to na szynie czy na mapowanej pamięci.

Tylko jakie to ma znaczenie? Jeśli projektujesz własne peryferia, np. na FPGA wtedy masz wpływ na adresy sprzętowe. Ale jeśli kupujesz gotowy układ , samo zdefiniowanie stałej czy typu nic nie daje.

mokrowski pisze:
elvis pisze:...siedzimy po nocach,

Nie będę tego komentował. Powody mogą być tylko patologiczne... jeśli tak jest to "źle się dzieje tak w projekcie" (jak i być może w firmie).

Jeśli nigdy nie pracowałeś po nocach, czy w weekendy bo jest obsuwa projektu, to trochę zazdroszczę, a trochę współczuję. Pierwsze, bo musiałeś trafiać na wyjątkowe firmy i projekty. Drugie, bo jeszcze dużo przed Tobą.

mokrowski pisze:Definicję warstwy sprzętu należy bezwzględnie zrobić. Powody są normatywne (mówi o tym standard Autosar, odpowiednie dla Med., Ind. Aero.... itd.). Daje to także możliwość sprawdzania statycznego kodu ze względu na konflikty adresacji co jest bezwzględnie konieczne w systemach zachowujących określony poziom bezpieczeństwa Nie stosujesz, nie dyskutuję bo nie musisz. Zrozum jednak że to jest zła praktyka uniemożliwiająca dostarczenie produktu w ww. sektorach. W moim przypadku jestem odpowiedzialny za QA oraz przygotowanie do certyfikowania poprawności kodu i (nie ukrywam) że zajmuję się "tępieniem" złego podejścia :/

O ile pamiętam autor wątku nie wspominał nic o formalnych wymaganiach odnośnie jego kodu. Więc fajnie, że np. MISRA coś zaleca, ale to o czym mówimy wcale nie musi być zgodne z akurat tym standardem. Który z resztą wcale taki fajny nie jest.

mokrowski pisze:
elvis pisze:Problem polega na tym, że samo ich wypisanie do dużo pracy..

Mam być bezpośredni? Za to Ci płacą :) Także i mi bym tego pilnował :) NIe wiem także czy to tak dużo pracy. Często nagłówek daje vendor lub robisz copy/paste z dokumentacji poddając to prostej obróbce.

Nie wiem dokładnie co robisz, ale ja nie pracuję jako typowy code-monkey i płacą mi a efekt, a nie za liczbę linijek kodu. Więc nie pisz mi, że mi płacą za pisanie czegoś co jest niepotrzebne.

A ogólnie to proponuję trochę ochłonąć i nie rozpoczynać g..no-burzy. Chciałem tylko doradzić autorowi wątku, ale oczywiście nie jest to ani zmuszanie kogoś do czegokolwiek, ani twierdzenie że pojadłem wszyskie rozumy i znam jedyną słuszną metodę na pisanie programów oraz zarządzanie projektami. Z mojego doświadczenia wynikają pewne spostrzeżenia, więc się nimi podzieliłem. Oczywiście jeśli dana firma ma swoje standardy - należy się do nich stosować.

Awatar użytkownika
mokrowski
User
User
Posty: 190
Rejestracja: czwartek 08 paź 2015, 20:50
Lokalizacja: Tam gdzie Centymetro

Re: Tworzenie oprogramowani dla systemów wbudowanych w firmach

Postautor: mokrowski » wtorek 03 lip 2018, 11:04

Nie rozpoczynam g-burzy. Podałem konkretne normy, odniosłem się do 2 rodzajów jakości, zauważyłem konsekwencje wypowiedzi. i przeczytałem ze zrozumieniem. Na tym skończę :)
,,Myślenie nie jest łatwe, ale można się do niego przyzwyczaić" - Alan Alexander Milne: Kubuś Puchatek

Awatar użytkownika
elvis
Posty: 12
Rejestracja: piątek 23 mar 2018, 09:49

Re: Tworzenie oprogramowani dla systemów wbudowanych w firmach

Postautor: elvis » wtorek 03 lip 2018, 11:10

W sumie też miałem skończyć - ale ostatnie zdanie mnie zaciekawiło. Czy Autosar lub MISRA to normy? Wydawało mi się, że normy to np. PN-EN62304, ale czy MISRA jest normą?

Awatar użytkownika
mokrowski
User
User
Posty: 190
Rejestracja: czwartek 08 paź 2015, 20:50
Lokalizacja: Tam gdzie Centymetro

Re: Tworzenie oprogramowani dla systemów wbudowanych w firmach

Postautor: mokrowski » wtorek 03 lip 2018, 11:20

Przeczytaj... a póżniej się odnieś...
,,Myślenie nie jest łatwe, ale można się do niego przyzwyczaić" - Alan Alexander Milne: Kubuś Puchatek

Awatar użytkownika
elvis
Posty: 12
Rejestracja: piątek 23 mar 2018, 09:49

Re: Tworzenie oprogramowani dla systemów wbudowanych w firmach

Postautor: elvis » wtorek 03 lip 2018, 11:27

No właśnie czytam, ale nadal mam wrażenie że MISRA jest po prostu standardem popularnym w automotive. Podałem przykład normy 62304, bo z nią dość dużo pracowałem - w zastosowaniach motoryzacyjnych nie mam niestety zbyt wiele doświadczenia. Chociaż ze standardem MISRA raz pracowałem, tylko że nie była to norma, ale standard dobrowolnie przyjęty w firmie.

Awatar użytkownika
mokrowski
User
User
Posty: 190
Rejestracja: czwartek 08 paź 2015, 20:50
Lokalizacja: Tam gdzie Centymetro

Re: Tworzenie oprogramowani dla systemów wbudowanych w firmach

Postautor: mokrowski » wtorek 03 lip 2018, 11:36

Opublikowałem wyłącznie 2 linki (by nie przytłaczać). Wystarczy w nie kliknąć. Zorientujesz się co jest normą co regułą a co dobrą praktyką. Jeśli zapytasz precyzyjne, co do Automotive mogę podpowiedzieć.
,,Myślenie nie jest łatwe, ale można się do niego przyzwyczaić" - Alan Alexander Milne: Kubuś Puchatek

Awatar użytkownika
elvis
Posty: 12
Rejestracja: piątek 23 mar 2018, 09:49

Re: Tworzenie oprogramowani dla systemów wbudowanych w firmach

Postautor: elvis » wtorek 03 lip 2018, 11:42

W tej chwili nie mam czasu na czytanie całego standardu Autosar, chociaż dziękuję za linki, może w wolnej chwili przeczytam.
Chodzi mi tylko o to, że pojęcie normy ma pewne ustalone znaczenie. https://www.pkn.pl/polskie-normy/normy- ... monizowane
Ponieważ użyłeś akurat tego słowa, a jak piszesz zajmujesz się zapewnianiem jakości pomyślałem, że pewnie rozumiesz czym się różni norma od standardu, więc zapytałem. Jeśli nie wiesz czy Autosar jest normą, to ok, tylko byłem ciekaw.

Awatar użytkownika
mokrowski
User
User
Posty: 190
Rejestracja: czwartek 08 paź 2015, 20:50
Lokalizacja: Tam gdzie Centymetro

Re: Tworzenie oprogramowani dla systemów wbudowanych w firmach

Postautor: mokrowski » wtorek 03 lip 2018, 11:55

elvis pisze:W tej chwili nie mam czasu na czytanie całego standardu Autosar

Kolego... ja podałem 2 linki.. Tylko 2 a ty nie masz czasu ich otworzyć i przeczytać że zawierają normy ISO które obowiązują dla tej branży (oczywiście kilka bo i dokumenty 2), odniesienie do standardów (czym jest także MISRA odnośnie kodowania ... choć zawiera także dobre praktyki), definicje dobrych praktyk.
IMHO warto na tym skończyć... i ew. zacząć czytanie (jeśli ktoś ma czas).
,,Myślenie nie jest łatwe, ale można się do niego przyzwyczaić" - Alan Alexander Milne: Kubuś Puchatek


Wróć do „Inne języki programowania”

Kto jest online

Użytkownicy przeglądający to forum: Obecnie na forum nie ma żadnego zarejestrowanego użytkownika i 8 gości