|
Twoja opinia
|
Jeśli potrzebujesz:
* system na inny typ procesora,
* chcesz zaproponować nowe funkcje.
Jeśli znalazłeś błąd na WWW
coś jest wyświetlane niewłaściwie lub nie działa w twojej przeglądarce.
Możesz wysłać wiadomość
Kliknik aby napisać wiadomość.
Twoje uwagi posłużą do ulepszenia systemu DioneOS.  
|
Wiadomości o DioneOS |
Pelna weryfikacja wersji systemu dla ARM Cortex-M3 2013-11-14 Wersja dla ARM Cortex-M3 zostala przetestowana automa- tycznie (pelne pokrycie kodu testami: wszystkie funkcje, makra, linie kodu, warunki itd.). Testy przeprowadzono na STM32L162. DioneOS na ARM Cortex-M3 2013-03-29 Wersja systemu DioneOS dla procesora ARM Cortex-M3 zostala opracowana. Wstep do wielowatkowosci 2011-07-11 'Wstep do wielowatkowosci' zostal dodany do sekcji prezentacji Obsluga maszyn stanowych 2011-06-15 Dodano infrastrukture do obslugi maszyn stanowych: kontrola przeplywu zdarzen, kolejki, przelaczanie stanow. Zdefiniowano wzorzec kodowania maszyn stanowych. Texas Instruments Developer Network 2011-04-11 Firma ELESOFTROM przystapila do programu 'Texas Instruments MCU Developer Network'. Program skupia firmy zajmujace sie oprogramowaniem dla mikro-kontrolerow Texas Instruments oraz swiadczeniem profesjo-nalnych uslug w tej dziedzinie. Wersja dla zwyklego MSP430 2011-04-05 Dodano mozliwosc kompilacji systemu na zwyky MSP430 oraz 'small code model'. Wersja systemu DioneOS dla MSP430x 2011-02-02 Pierwsza wersja systemu DioneOS. System obsluguje architekture MSP430x oraz 'large code model'.
|
|
Niezawodnośc systemu DioneOS
Wersja systemu przeznaczona dla procesorów ARM Cortex-M3 została poddana szczegółowym testom. Testy przeprowadzono na
procesorze ST Microelectronics STM32L162. Do kompilacji wykorzystano własny toolchain z kompilatorem GNU GCC oraz biblioteką newlib jako libc.
Jakość kompilowanego kodu
"Zero tolerancji" dla błędów, ostrzeżeń, niejasnego działania!
- kompilacja ze szczegółowym raportowaniem ostrzeżeń i błędów (-Wall --pedantic)
- uzyskano kompilację bez ostrzeżeń *
- unikanie niebezpiecznych konstrukcji
- stosowanie dobrze sprawdzonych rozwiązań
- obserwacja działania, każde niejasne działanie jest analizowane i wyjaśniane (testy dodatkowe, wnikliwe studiowanie dokumentacji architektury procesora).
Jak system DioneOS jest testowany
- środowisko do automatycznego testowania kodu (OpenOCD, cross-GDB, JTAG, Analizator Logiczny, skrypty...)
- plan testów uwzględniajacy sprawdzenie poprawnego działania wszystkich funkcji i makrodefinicji
- testy są wykonywane automatycznie
- testowanie na docelowym procesorze
Zakres testów
Pełen zestaw przekracza 400 testów (przykładowy raport z testów)
Wykonywane testy zapewniają pełne pokrycie kodu:
- moduły
- funkcje
- wszystkie linie kodu (C i ASM)
- wszystkie makra
- wszystkie warunki i decyzje w instrukcjach warunkowych
- wszystkie punkty wyjścia z funkcji (w tym wyjątki)
- sprawdzenie różnych opcji konfiguracyjnych, prowadzących do kompilacji warunkowej
Co jest testowane
- testowanie działania funkcji, czy jest zgodne ze specyfikacją,
- testowanie zwracanych kodów błędów
- testowanie wykrywania błędów czasu wykonania i generowania wyjątków,
- testowanie kodu pod względem hazardu podczas wywoływania przerwań w różnych miejscach (wiecej na ten temat...)
- przeanalizowano i uzwględniono zaawansowane cechy architektury Cortex-M3 i ich wpływ na działanie (Late Arriving Interrupt, Tail-Chaining, Pipeline, itp.)
*) - kompilator zgłaszał ostrzeżenie podczas budowania biblioteki STM32L1xx_StdPeriph_Lib w module stm32l1xx_flash_ramfunc:
stm32l1xx_flash_ramfunc.s: Assembler messages:
stm32l1xx_flash_ramfunc.s:18: Warning: ignoring changed section attributes for .data
Powodem ostrzeżenia jest celowe umieszczenie funkcji dotyczących operacji na pamięci flash w RAM w sekcji .data. Sekcja .data posiada atrybuty pamięci do odczytu i zapisu,
podczas gdy umieszczanie tam kodu prowadzi do próby wymuszenia atrybutów do wykonania i odczytu. Jest to pewnego rodzaju skrót zastosowany przez twórców biblioteki (zamiast
utworzyć osobną sekcję na taki kod i zapewnić inicjalizację takiej sekcji korzystają oni z gotowego zachowania inicjalizowanych danych w .data).
Niemniej jednak, kod jest umieszczany prawidłowo w RAM, jego wywołanie z flash posiada prawidłowe opakowanie (veneer) i jest właściwie wykonywany.
|
|