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.